8 ms·

Time Zone Bugs I Ran Into

54 points by Sandeepg33k 6y ago

CodesInChaos 6y ago
The most annoying timezone issue I encountered is that the timezone offsets can change (typically only for future times). So you if you store local times as UTC, you might not get back the correct value when you convert back after a tzinfo update (especially dangerous if you use the OS provided timezone data, since that makes it more difficult to control when it's updated). Always store the authoritative version of a time, which usually is UTC for points in time, but local time for calendar based things. The duplicate/missing hour around DST switching can also be quite annoying.
- mjevans 6y ago
  For an absolute event that was observed, UTC is, indeed, correct. For anything interacting with planning though, the user's needs should be considered. Often what you actually want to store is a "recurrence rule" for a single event, while being sure to include the defining aspects picked, or at least confirmed, by the user.
- maxmax_ 6y ago
  > The duplicate/missing hour around DST switching can also be quite annoying. Oh yes. I used to work for company which produced medical software which continuously recorded patient data. Those duplicated or missing hours were always the worst and error-prone use cases.
  - Mountain_Skies 6y ago
    More than one vendor has become rather upset when I've demanded that they handle those situations appropriately. But much of what I do involves automation so I don't want any surprises or in this situation, two known exceptional cases that need to be accounted for. Also I find this to be a code smell, like brown M&Ms in a contract rider. Don't know if they've fixed it but when I had a Fitbit, they never was able to get these DST change over events handled correctly. What's worse is that their website and their app both handled the change over in different ways, both wrong.
    - CodesInChaos 6y ago
      What do you mean by handle appropriately here? This is one of the cases where I'd simply store UTC and display the (sometimes ambiguous) local time in the UI.
      - Mountain_Skies 6y ago
        The problem was that they weren't storing events in UTC but were using local server time instead. They had no explanation for what would happen during the switch from daylight time to standard time but couldn't rule out the possibility of out of order events happening due to it.
- dmm 6y ago
  > So you if you store local times as UTC, you might not get back the correct value when you convert back after a tzinfo update That shouldn't be a problem for datetimes in the past. tzdata contains not only the current offset but all historical ones as well. It might be a problem for /future/ datetimes. If I say the meeting is at 1700 America/New_York and the local civil authority changes the offset in the meantime I probably don't want the meeting to move in local time.
  - jmiserez 6y ago
    Unfortunately no, it can be a problem even for past dates. The new java.time and old java.util.TimeZone APIs use different offsets for dates < 1990, which resulted in a difference of 6 minutes and 32 seconds for my dates. I filed a bug (JDK-8214243) but basically it's a known issue and there's no fix.
    - CodesInChaos 6y ago
      When migrating from .net's TimeZoneInfo (based on windows timezones) to NodaTime (based on tzdb) we ran into differences in the mid nineties for the German timezone.
- netsharc 6y ago
  Yeah, 1 realization I made a long time ago was a day could have 25 hours or 23 hours. And a clever system having a timeline would show, e.g. in the Central European timezone: 1 AM, 2 AM (CET), 2 AM (CEST), 3 AM, 4 AM... or 1 AM, 2 AM (CEST), 4 AM (CET), 5 AM, ...
  - Piskvorrr 6y ago
    There's an intriguing way that railways handle the transition around here (central Europe): one way, trains stop in stations for an hour, the other, they all get an +1 hr delay at next station.
    - nelaboras 6y ago
      Sorry but do you have a citation on that? Never seen anything like that in Europe.
      - netsharc 6y ago
        Not original commenter, but basically he's right, according to the German Rail (in German): https://www.deutschebahn.com/pr-hamburg-de/hintergrund/themendienste/Zeitumstellung-1310956 https://www.deutschebahn.com/pr-hamburg-de/hintergrund/theme... If a night loses 1 hour, the train stops for less time at the scheduled stops, or arrives with a delay. If the night gains an hour, the train waits somewhere for an hour. Which sounds like a painful thing, having to travel (or wait) an extra hour because of clocks. Interestingly if the night loses an hour, the trains are automatically an hour behind schedule...
        andi999 6y ago
        Beeing an hour behind schedule is not that uncommon.....
      - Piskvorrr 6y ago
        Other than [OWNRESEARCH], i.e. experienced that a few times? Not really, no.
- Piskvorrr 6y ago
  Missing hour, ha! The Norwegians have apparently named their Antarctic station Troll for a reason: the TZ Antarctica/Troll uses UTC/UTC+2 - great way to test/break things that need to work with dates.
  - CodesInChaos 6y ago
    To really troll software developers they should repeat one hour three times, instead of repeating two hours twice.
    - willis936 6y ago
      I feel like this would also troll everyone in their society. >What time is it? 2am. >It’s been 2am for 2 hours!
square_usual 6y ago
This blog page, ostensibly just text and images, made 30 requests for javascript files, and several more to analytics. In all, it made 62 requests over 50 seconds, transferring 1.9Mb - for less than a thousand words of content. Why?
- FandangoRanger 6y ago
  Listen blogging isn’t easy so you, the reader, are going to have to pay one way or another.
  - Eikon 6y ago
    > the reader, are going to have to pay one way or another. Many blogs don’t exist as a way to produce an income and absolutely don’t have enough traffic to do so.
- lmilcin 6y ago
  It seems to me you have just awoken from 20 year of coma. Welcome to 2020. A lot has changed. People still use phones to access Internet but not exactly the same way (you may want to get updated on this in the closest Apple store. No, not a store with apples either). Oh, and please, were a mask.
- MattGaiser 6y ago
  Because it is 1000 words of content with the ability for you to comment on the content, click one of many numerous react options, retweet it, bookmark it, see how long it will take you to read, view other posts with the same tags, for the developer to know who visited, where they visited from, what time they visited, and where else on the site they went and be all presumably configurable as it is not a website the developer made, but built with a blogging platform. It is a full fledged web app because it is a web app for managing thousands of different blogs and doing dozens of little random features, each of which has their own little bit of JS.
  - robin_reala 6y ago
    I guess you answered the technical part of the original ”Why?” question, but the subtext of ”How did we arrive at this state?” remains a mystery.
lifthrasiir 6y ago
On Java: it had been a common sightseeing in the IANA tz mailing list that some complained about TZUpdater [1] not working. It's amusing if not annoying, and the root cause traces back to the intricacy of time zones themselves. Apparently some countries at some points had (and sometimes, like Ireland [2], have) a "winter time" as opposed to a "summer time". In the other words their standard time takes place in summer and the "winter time" has a negative offset to the standard time. Technically this is not different from a "summer time" in other countries, but C `struct tm` has a `tm_isdst` flag that ideally should be true in winter for those countries. tzdata made transition to support negative DST offsets in early 2018, but this caused unwanted software problems so the choise was made to support the "rearguard" format that doesn't have negative DST offsets. This was an one-off incident for most cases, but TZUpdater didn't support the more recent (and more correct) "vanguard" format. And yet users tend to feed the vanguard format to TZUpdater and thought tzdata was at fault. This annoyance continued until TZUpdater finally supported the rearguard format in late 2019 (I think). [1] https://www.oracle.com/java/technologies/javase/tzupdater-readme.html https://www.oracle.com/java/technologies/javase/tzupdater-re... [2] https://en.wikipedia.org/wiki/Time_in_the_Republic_of_Ireland https://en.wikipedia.org/wiki/Time_in_the_Republic_of_Irelan...
LittlePeter 6y ago
The POSIX timezones having - and + reversed once cost me a day of pulling hairs: http://www.pixelbeat.org/docs/linux_timezones/ http://www.pixelbeat.org/docs/linux_timezones/
robin_reala 6y ago
Appropriate to link to the classic “Falsehoods programmers believe about time” here: https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program...
- lmilcin 6y ago
  Time is one of the easiest ways to find a bug in a backend app. Search for "23:59:59" or any use of local server time and you got yourself a bug. I work for one of the largest banks in the world and I get to see a lot of code for some mundane backend stuff. For some reasons, people think that the day has always 23 hour, 59 minutes and 59 seconds and that there is a one second delay between one day ending and another starting. Then they are incredulous some trades have vanished. There was a serious movement to stop data flowing around midnight until I reminded everybody that midnight happens 24 times a day (and not even that, there are fractional timezones, DST, etc. to complicate matters).
  - willis936 6y ago
    This sounds like an Office Space-esque rounding error. I recently wrote some code that requests all entries in a single day. The time query range is 00:00:00 to 23:59:59.999999999. I haven’t checked if nanosecond precision is sufficient for the timestamp source (labview requesting datetime from Windows 7), but I’m under the impression it is. If I was handling something higher stakes like finances, I would tack on a few more 9s.
    - corty 6y ago
      Well then, let me introduce you to the regularly occurring 23:59:60: https://en.m.wikipedia.org/wiki/Leap_second https://en.m.wikipedia.org/wiki/Leap_second
      - imglorp 6y ago
        Some of the cloud hosting NTP environments abolish leaps by smearing them out over a long period. That's one way to help out application code unprepared for them. More surprising is that a number of expensive, precision, commercial GPS chips do NOT all handle leap seconds the same way. I worked in a shop that used about three different ones for their PPS and clock outputs and we got about three different behaviors from them. Evidently the leap seconds are broadcast in supplementary data and then applied on chip when it produces a UTC output.
lklcxkkdk 6y ago
As I am currently struggling with time zones on Java, I want to mention the implementation by the unicode organization: https://unicode-org.github.io/icu-docs/apidoc/released/icu4j/ https://unicode-org.github.io/icu-docs/apidoc/released/icu4j... I found it very useful.
seanhunter 6y ago
My favourite TZ bug was where thanks to a timezone bug some (but not all) events were showing up a day early after our etl. It turned out that a combination of several seemingly logical steps we had managed to end up in an insane place. If you just want the tldr, dates are not times, don't store dates as times or you can be bitten by timezone bugs. Also dates don't have a timezone, don't store them as something that has a timezone or you can make mistakes. So: 1)We decided to store all timestamps as UTC. A bunch of analysis we were doing was temporal so it was really important to be able to compare timestamps coming from different source systems (with different native timestamps) accurately. 2)Some events were things occurring on specific dates rather than at a particular time. No problem, dates don't have a timezone. We can't possibly be bitten by a timezone bug on dates. 3)One of our serialization formats didn't have a date type so we decided to store dates as times with a timestamp of midnight (This is ancient Pig-era hadoop so you're probably talking an earlyish avro format but I can't remember). You can always just chop the time off to turn them back to a date and nothing can possibly go wrong. 4)One of the event source systems used Europe/London timezone (ie daylight savings in the summer, GMT in the winter) as the system tz rather than UTC. No big deal right, we're doing consistent UTC conversion so this couldn't possibly hurt anything. Bingo! Some of the date based events appeared one day earlier than they should. Do you see why? This was an absolute bastard to debug because it was in the middle of a somewhat flakey data pipeline taht used to take >9hrs to run but basically what was happening is during daylight savings months these events were being converted from 00:00 1 Aug BST (say) to 23:00 31 July UTC, so when serialised once you chopped off the time the event would end up one day early. It wasn't all dates because not all days are during daylight savings and events that had an actual time (not a date that had been turned into a time) were of course fine. Also date events that were recorded on a system that used UTC as its system timezone were also fine.
- superjan 6y ago
  Many people use datetime data types for dates, some unknowingly, some don’t care and some because they don’t see an alternative. Its quite strange there is rarely language/library support for true, not timezone dependent dates.
  - 6y ago
mumblerino 6y ago
Can’t most of these issues be solved by not using timezones at all on servers? All data should be UTC; timezones only apply when the data is shown to the user, possibly on the client itself, which likely can automatically display the right time for a UTC date.
- masklinn 6y ago
  If you’re actually working with dates (e.g. calendaring), storing dates as UTC is a potentially critical loss of information. Basically, UTC is mostly fine for recording past events (e.g. event logs though even then pre-1970 events can be problematic), but for any future event it’s very risky, because time zones « move around » sometimes with very little heads up (down to weeks if not days for DST) but a user working in a specific time one expects their stuff to be fixed in their time zones’ frame of reference. But of course this indices the problem of ambiguity around DST switch & other backwards TZ movements.
- CodesInChaos 6y ago
  That is usually enough when recording events that happened at a specific point in time. Even then you sometimes want to record the offset in the user's timezone, so you know the relevant local time (e.g. when taking a photo). But it's not enough for things agreed to happen in a specific time zone (meetings, contracts, subscription billing, etc.) In those cases you have to record the local time and timezone name (plus disambiguation for DST switching) and figure out how to handle changes of the timezone definition (e.g. by updating denormalized UTC representations or offsets).
- yosamino 6y ago
  It's a question of knowing your data. UTC time probably won't always give you the correct result, since timezones and DST aren't fixed. Say, you want to store the time of your doctor's appointment months in advance. Here it makes sense to store the time with a timezone - but not the timezone offset. This makes sense because no matter what the government decides about changing DST or moving timezone offsets alltogether - your doctor's appointment is going to be at 0900am at a specific geographic location and since you will physically be there with your watch synchronized to your doctor's. But say you have an online appointment with your psychotherapist who lives in a completely different timezone (possibly you do not know which one) from you at some specific time in the future. Here making the appointment via UTC makes sense - to meet up you need a globally synchronized clock. The hard part: how do you know determine whether you can schedule these two one-hour appointments right after each other and not have a conflict ? I am not sure it's perfectly possible.
chrisBob 6y ago
My favorite(1) way of dealing with timezones is how Fitbit does it: They just ignore the fact that they exist! They will give you accurate minute-by-minute heart rate data for a someone, but what timezone did that occur in? Whatever one the watch was set to when it happened. What if I live on the East Coast and fly to California and back and what to see how my body reacted to the trip? Well some times will happen twice (and get overwritten), some will never happen, and who knows when the change happened in the middle (probably when you happened to sync your Fitbit, sometime after your phone changed timezones). (1) To complain about
GistNoesis 6y ago
I have encountered some bugs related to time zone, when using cheap surveillance cameras, for which the time zone/ Daylight Saving Time doesn't always work properly. The displayed time inside the video feed may be off by one hour / also different than the time the notification email. I have encountered some bugs related to time zone with docker in which the displayed time in the displayed console log output is different from the local time, which is kind of confusing when reporting issues on github. But if your code isn't done properly and have filters based on local time you need remember to pass the correct time zone configuration when shipping with docker. When reading blog posts / social media / messaging apps you need to be aware of the "responded at xxxx time" usually is local relative to the poster, which may cause confusing anachronism, when trying to know if the message is before or after an event. (If you get the time via an API, it usually is UTC, but when you are scrapping you need to be careful). Also with DST you always need to check that your alarm clocks have the correct date so they change correctly. Semi-related, on a dual booting linux/windows, my windows machine after reboot is usually still in the past at the time when it was last shut off, which prevents logging into Fusion360 (without signaling why the server refuse the connection), until my windows get it's time at the right time by synchronizing with the ntp time server.

54 points by Sandeepg33k 6y ago

The most annoying timezone issue I encountered is that the timezone offsets can change (typically only for future times). So you if you store local times as UTC, you might not get back the correct value when you convert back after a tzinfo update (especially dangerous if you use the OS provided timezone data, since that makes it more difficult to control when it's updated). Always store the authoritative version of a time, which usually is UTC for points in time, but local time for calendar based things. The duplicate/missing hour around DST switching can also be quite annoying.

mjevans 6y ago
For an absolute event that was observed, UTC is, indeed, correct. For anything interacting with planning though, the user's needs should be considered. Often what you actually want to store is a "recurrence rule" for a single event, while being sure to include the defining aspects picked, or at least confirmed, by the user.
maxmax_ 6y ago
> The duplicate/missing hour around DST switching can also be quite annoying. Oh yes. I used to work for company which produced medical software which continuously recorded patient data. Those duplicated or missing hours were always the worst and error-prone use cases.
- Mountain_Skies 6y ago
  More than one vendor has become rather upset when I've demanded that they handle those situations appropriately. But much of what I do involves automation so I don't want any surprises or in this situation, two known exceptional cases that need to be accounted for. Also I find this to be a code smell, like brown M&Ms in a contract rider. Don't know if they've fixed it but when I had a Fitbit, they never was able to get these DST change over events handled correctly. What's worse is that their website and their app both handled the change over in different ways, both wrong.
  - CodesInChaos 6y ago
    What do you mean by handle appropriately here? This is one of the cases where I'd simply store UTC and display the (sometimes ambiguous) local time in the UI.
    - Mountain_Skies 6y ago
      The problem was that they weren't storing events in UTC but were using local server time instead. They had no explanation for what would happen during the switch from daylight time to standard time but couldn't rule out the possibility of out of order events happening due to it.
dmm 6y ago
> So you if you store local times as UTC, you might not get back the correct value when you convert back after a tzinfo update That shouldn't be a problem for datetimes in the past. tzdata contains not only the current offset but all historical ones as well. It might be a problem for /future/ datetimes. If I say the meeting is at 1700 America/New_York and the local civil authority changes the offset in the meantime I probably don't want the meeting to move in local time.
- jmiserez 6y ago
  Unfortunately no, it can be a problem even for past dates. The new java.time and old java.util.TimeZone APIs use different offsets for dates < 1990, which resulted in a difference of 6 minutes and 32 seconds for my dates. I filed a bug (JDK-8214243) but basically it's a known issue and there's no fix.
  - CodesInChaos 6y ago
    When migrating from .net's TimeZoneInfo (based on windows timezones) to NodaTime (based on tzdb) we ran into differences in the mid nineties for the German timezone.
netsharc 6y ago
Yeah, 1 realization I made a long time ago was a day could have 25 hours or 23 hours. And a clever system having a timeline would show, e.g. in the Central European timezone: 1 AM, 2 AM (CET), 2 AM (CEST), 3 AM, 4 AM... or 1 AM, 2 AM (CEST), 4 AM (CET), 5 AM, ...
- Piskvorrr 6y ago
  There's an intriguing way that railways handle the transition around here (central Europe): one way, trains stop in stations for an hour, the other, they all get an +1 hr delay at next station.
  - nelaboras 6y ago
    Sorry but do you have a citation on that? Never seen anything like that in Europe.
    - netsharc 6y ago
      Not original commenter, but basically he's right, according to the German Rail (in German): https://www.deutschebahn.com/pr-hamburg-de/hintergrund/themendienste/Zeitumstellung-1310956 https://www.deutschebahn.com/pr-hamburg-de/hintergrund/theme... If a night loses 1 hour, the train stops for less time at the scheduled stops, or arrives with a delay. If the night gains an hour, the train waits somewhere for an hour. Which sounds like a painful thing, having to travel (or wait) an extra hour because of clocks. Interestingly if the night loses an hour, the trains are automatically an hour behind schedule...
      - andi999 6y ago
        Beeing an hour behind schedule is not that uncommon.....
    - Piskvorrr 6y ago
      Other than [OWNRESEARCH], i.e. experienced that a few times? Not really, no.
Piskvorrr 6y ago
Missing hour, ha! The Norwegians have apparently named their Antarctic station Troll for a reason: the TZ Antarctica/Troll uses UTC/UTC+2 - great way to test/break things that need to work with dates.
- CodesInChaos 6y ago
  To really troll software developers they should repeat one hour three times, instead of repeating two hours twice.
  - willis936 6y ago
    I feel like this would also troll everyone in their society. >What time is it? 2am. >It’s been 2am for 2 hours!

square_usual 6y ago

This blog page, ostensibly just text and images, made 30 requests for javascript files, and several more to analytics. In all, it made 62 requests over 50 seconds, transferring 1.9Mb - for less than a thousand words of content. Why?

FandangoRanger 6y ago
Listen blogging isn’t easy so you, the reader, are going to have to pay one way or another.
- Eikon 6y ago
  > the reader, are going to have to pay one way or another. Many blogs don’t exist as a way to produce an income and absolutely don’t have enough traffic to do so.
lmilcin 6y ago
It seems to me you have just awoken from 20 year of coma. Welcome to 2020. A lot has changed. People still use phones to access Internet but not exactly the same way (you may want to get updated on this in the closest Apple store. No, not a store with apples either). Oh, and please, were a mask.
MattGaiser 6y ago
Because it is 1000 words of content with the ability for you to comment on the content, click one of many numerous react options, retweet it, bookmark it, see how long it will take you to read, view other posts with the same tags, for the developer to know who visited, where they visited from, what time they visited, and where else on the site they went and be all presumably configurable as it is not a website the developer made, but built with a blogging platform. It is a full fledged web app because it is a web app for managing thousands of different blogs and doing dozens of little random features, each of which has their own little bit of JS.
- robin_reala 6y ago
  I guess you answered the technical part of the original ”Why?” question, but the subtext of ”How did we arrive at this state?” remains a mystery.

lifthrasiir 6y ago

On Java: it had been a common sightseeing in the IANA tz mailing list that some complained about TZUpdater [1] not working. It's amusing if not annoying, and the root cause traces back to the intricacy of time zones themselves. Apparently some countries at some points had (and sometimes, like Ireland [2], have) a "winter time" as opposed to a "summer time". In the other words their standard time takes place in summer and the "winter time" has a negative offset to the standard time. Technically this is not different from a "summer time" in other countries, but C `struct tm` has a `tm_isdst` flag that ideally should be true in winter for those countries. tzdata made transition to support negative DST offsets in early 2018, but this caused unwanted software problems so the choise was made to support the "rearguard" format that doesn't have negative DST offsets. This was an one-off incident for most cases, but TZUpdater didn't support the more recent (and more correct) "vanguard" format. And yet users tend to feed the vanguard format to TZUpdater and thought tzdata was at fault. This annoyance continued until TZUpdater finally supported the rearguard format in late 2019 (I think). [1] https://www.oracle.com/java/technologies/javase/tzupdater-readme.html https://www.oracle.com/java/technologies/javase/tzupdater-re... [2] https://en.wikipedia.org/wiki/Time_in_the_Republic_of_Ireland https://en.wikipedia.org/wiki/Time_in_the_Republic_of_Irelan...

LittlePeter 6y ago

The POSIX timezones having - and + reversed once cost me a day of pulling hairs: http://www.pixelbeat.org/docs/linux_timezones/ http://www.pixelbeat.org/docs/linux_timezones/

robin_reala 6y ago

Appropriate to link to the classic “Falsehoods programmers believe about time” here: https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program...

lmilcin 6y ago
Time is one of the easiest ways to find a bug in a backend app. Search for "23:59:59" or any use of local server time and you got yourself a bug. I work for one of the largest banks in the world and I get to see a lot of code for some mundane backend stuff. For some reasons, people think that the day has always 23 hour, 59 minutes and 59 seconds and that there is a one second delay between one day ending and another starting. Then they are incredulous some trades have vanished. There was a serious movement to stop data flowing around midnight until I reminded everybody that midnight happens 24 times a day (and not even that, there are fractional timezones, DST, etc. to complicate matters).
- willis936 6y ago
  This sounds like an Office Space-esque rounding error. I recently wrote some code that requests all entries in a single day. The time query range is 00:00:00 to 23:59:59.999999999. I haven’t checked if nanosecond precision is sufficient for the timestamp source (labview requesting datetime from Windows 7), but I’m under the impression it is. If I was handling something higher stakes like finances, I would tack on a few more 9s.
  - corty 6y ago
    Well then, let me introduce you to the regularly occurring 23:59:60: https://en.m.wikipedia.org/wiki/Leap_second https://en.m.wikipedia.org/wiki/Leap_second
    - imglorp 6y ago
      Some of the cloud hosting NTP environments abolish leaps by smearing them out over a long period. That's one way to help out application code unprepared for them. More surprising is that a number of expensive, precision, commercial GPS chips do NOT all handle leap seconds the same way. I worked in a shop that used about three different ones for their PPS and clock outputs and we got about three different behaviors from them. Evidently the leap seconds are broadcast in supplementary data and then applied on chip when it produces a UTC output.

lklcxkkdk 6y ago

As I am currently struggling with time zones on Java, I want to mention the implementation by the unicode organization: https://unicode-org.github.io/icu-docs/apidoc/released/icu4j/ https://unicode-org.github.io/icu-docs/apidoc/released/icu4j... I found it very useful.

seanhunter 6y ago

My favourite TZ bug was where thanks to a timezone bug some (but not all) events were showing up a day early after our etl. It turned out that a combination of several seemingly logical steps we had managed to end up in an insane place. If you just want the tldr, dates are not times, don't store dates as times or you can be bitten by timezone bugs. Also dates don't have a timezone, don't store them as something that has a timezone or you can make mistakes. So: 1)We decided to store all timestamps as UTC. A bunch of analysis we were doing was temporal so it was really important to be able to compare timestamps coming from different source systems (with different native timestamps) accurately. 2)Some events were things occurring on specific dates rather than at a particular time. No problem, dates don't have a timezone. We can't possibly be bitten by a timezone bug on dates. 3)One of our serialization formats didn't have a date type so we decided to store dates as times with a timestamp of midnight (This is ancient Pig-era hadoop so you're probably talking an earlyish avro format but I can't remember). You can always just chop the time off to turn them back to a date and nothing can possibly go wrong. 4)One of the event source systems used Europe/London timezone (ie daylight savings in the summer, GMT in the winter) as the system tz rather than UTC. No big deal right, we're doing consistent UTC conversion so this couldn't possibly hurt anything. Bingo! Some of the date based events appeared one day earlier than they should. Do you see why? This was an absolute bastard to debug because it was in the middle of a somewhat flakey data pipeline taht used to take >9hrs to run but basically what was happening is during daylight savings months these events were being converted from 00:00 1 Aug BST (say) to 23:00 31 July UTC, so when serialised once you chopped off the time the event would end up one day early. It wasn't all dates because not all days are during daylight savings and events that had an actual time (not a date that had been turned into a time) were of course fine. Also date events that were recorded on a system that used UTC as its system timezone were also fine.

superjan 6y ago
Many people use datetime data types for dates, some unknowingly, some don’t care and some because they don’t see an alternative. Its quite strange there is rarely language/library support for true, not timezone dependent dates.
- 6y ago

mumblerino 6y ago

Can’t most of these issues be solved by not using timezones at all on servers? All data should be UTC; timezones only apply when the data is shown to the user, possibly on the client itself, which likely can automatically display the right time for a UTC date.

masklinn 6y ago
If you’re actually working with dates (e.g. calendaring), storing dates as UTC is a potentially critical loss of information. Basically, UTC is mostly fine for recording past events (e.g. event logs though even then pre-1970 events can be problematic), but for any future event it’s very risky, because time zones « move around » sometimes with very little heads up (down to weeks if not days for DST) but a user working in a specific time one expects their stuff to be fixed in their time zones’ frame of reference. But of course this indices the problem of ambiguity around DST switch & other backwards TZ movements.
CodesInChaos 6y ago
That is usually enough when recording events that happened at a specific point in time. Even then you sometimes want to record the offset in the user's timezone, so you know the relevant local time (e.g. when taking a photo). But it's not enough for things agreed to happen in a specific time zone (meetings, contracts, subscription billing, etc.) In those cases you have to record the local time and timezone name (plus disambiguation for DST switching) and figure out how to handle changes of the timezone definition (e.g. by updating denormalized UTC representations or offsets).
yosamino 6y ago
It's a question of knowing your data. UTC time probably won't always give you the correct result, since timezones and DST aren't fixed. Say, you want to store the time of your doctor's appointment months in advance. Here it makes sense to store the time with a timezone - but not the timezone offset. This makes sense because no matter what the government decides about changing DST or moving timezone offsets alltogether - your doctor's appointment is going to be at 0900am at a specific geographic location and since you will physically be there with your watch synchronized to your doctor's. But say you have an online appointment with your psychotherapist who lives in a completely different timezone (possibly you do not know which one) from you at some specific time in the future. Here making the appointment via UTC makes sense - to meet up you need a globally synchronized clock. The hard part: how do you know determine whether you can schedule these two one-hour appointments right after each other and not have a conflict ? I am not sure it's perfectly possible.

chrisBob 6y ago

My favorite(1) way of dealing with timezones is how Fitbit does it: They just ignore the fact that they exist! They will give you accurate minute-by-minute heart rate data for a someone, but what timezone did that occur in? Whatever one the watch was set to when it happened. What if I live on the East Coast and fly to California and back and what to see how my body reacted to the trip? Well some times will happen twice (and get overwritten), some will never happen, and who knows when the change happened in the middle (probably when you happened to sync your Fitbit, sometime after your phone changed timezones). (1) To complain about

GistNoesis 6y ago

I have encountered some bugs related to time zone, when using cheap surveillance cameras, for which the time zone/ Daylight Saving Time doesn't always work properly. The displayed time inside the video feed may be off by one hour / also different than the time the notification email. I have encountered some bugs related to time zone with docker in which the displayed time in the displayed console log output is different from the local time, which is kind of confusing when reporting issues on github. But if your code isn't done properly and have filters based on local time you need remember to pass the correct time zone configuration when shipping with docker. When reading blog posts / social media / messaging apps you need to be aware of the "responded at xxxx time" usually is local relative to the poster, which may cause confusing anachronism, when trying to know if the message is before or after an event. (If you get the time via an API, it usually is UTC, but when you are scrapping you need to be careful). Also with DST you always need to check that your alarm clocks have the correct date so they change correctly. Semi-related, on a dual booting linux/windows, my windows machine after reboot is usually still in the past at the time when it was last shut off, which prevents logging into Fusion360 (without signaling why the server refuse the connection), until my windows get it's time at the right time by synchronizing with the ntp time server.