Created
June 24, 2018 19:15
-
-
Save DannyvdSluijs/ac5e0e1ea6c7a5d5c3000008222044c8 to your computer and use it in GitHub Desktop.
Potential loss of zonetime info storing DateTime and DateTimeZone in DB
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| <?php | |
| echo (DatetimeImmutable ::createFromFormat ('U', 1540686600, new DateTimeZone('UTC'))) | |
| ->setTimeZone(new DateTimeZone('Europe/Amsterdam')) | |
| ->format('d-m-Y H:i:s (e P)'); | |
| // 28-10-2018 02:30:00 (Europe/Amsterdam +02:00) | |
| echo (DatetimeImmutable ::createFromFormat ('U', 1540690200, new DateTimeZone('UTC'))) | |
| ->setTimeZone(new DateTimeZone('Europe/Amsterdam')) | |
| ->format('d-m-Y H:i:s (e P)'); | |
| // 28-10-2018 02:30:00 (Europe/Amsterdam +01:00) | |
| echo (new DatetimeImmutable('2018-10-28 02:30:00', new DateTimeZone('Europe/Amsterdam'))) | |
| ->format('d-m-Y H:i:s (e P)'); | |
| // 28-10-2018 02:30:00 (Europe/Amsterdam +01:00) | |
| // How would we have stored the first case as DateTime and DateTimeZone values using an DST observing timezone ?? |
Author
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Thank @heiglandreas for that detailed reply. And reading your blog it seems scary indeed (Also knowing that we store all in UTC, mainly as the data comes from computer systems, IoT sensors and GPS devices and already is in UTC). I find peace in the fact that we only store historical timestamps e.g. no political DST shifts that jump out and surprise us. Assuming we need to keep the the timezone-database up to date.
Thanks again for share with me and improving my knowledge on timezones.