4 ms·

Another common reason that time goes backwards is DST. The amount of DST-related bugs that I've fixed over the years amazes me, because every single developer h

Another common reason that time goes backwards is DST. The amount of DST-related bugs that I've fixed over the years amazes me, because every single developer has moved clocks back and forth twice a year for their entire lives, bar a few years in the beginning. And even this fine article mentions the time-has-gone-back possibility yet ignores DST.

WirelessGigabit 3y ago
Oh the joys of living in Arizona! Not having to deal with confusion twice per year! Not having to deal with these sort issues! Or so I thought. All calendar invites I own are set in Arizona time, so for everybody else they shift. Queue the rescheduling requests. For the ones I don't own it actually is better for me as they all shift an hour later.
aljarry 3y ago
> time goes backwards is DST Only if you deal with timestamps that don't contain timezone information. With TIMESTAMPTZ in postgres it's transparent, you don't have to do anything specifically to manage DST.
- realaleris149 3y ago
  Postgres does not store the actual time zone information, it just stores it in UTC. Is a bit counterintuitive but this is how it works [1]. The "with time zone" part is just for parsing and displaying back. When is displayed the value is converted from UTC to the local time in the current timezone which can result in some very interesting discussions :). [1] https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-DATETIME-INPUT-TIME-STAMPS https://www.postgresql.org/docs/current/datatype-datetime.ht...
  - aljarry 3y ago
    TIL :) thanks, I misunderstood that part.
loloquwowndueo 3y ago
Every single US developer maybe. In Mexico DST started in 1994 so developers who started before that (hello!) did need some adjustment and operating system support was not a given. There are also countries where DST is not observed or differs from the US yet developers from those countries might be working remotely for a US company, with US developers or needing to accommodate a significant US clientele.
- dotancohen 3y ago
  I'm not in the US.
- gwbas1c 3y ago
  DST is common throughout the world: The days that it starts and stops vary, both by locale, and by year. The operating system keeps track of every locale's DST dates, all the way as long as DST has been a thing. When governments change the date, via law changes, the change usually gets passed along in an OS update.
  - deleted 3y ago
    [deleted]
  - o11c 3y ago
    Note that Windows has major bugs here - from memory, it only keeps track of the 2 most recent DST rules, so historical timestamps will be wrong after the rules change twice.
  - pritambaral 3y ago
    Reporting from India here. No DST ever. I still know what DST is and how it works, but I've never had to change clocks due to DST.
  - mook 3y ago
    Looking at the Wikipedia article, it looks like it's not that popular in Asia and Africa. Lots of places seems to have observed it at some point in the past, though a lot of them seem to have been last century. https://en.m.wikipedia.org/wiki/Daylight_saving_time_by_country https://en.m.wikipedia.org/wiki/Daylight_saving_time_by_coun...
gwbas1c 3y ago
> The amount of DST-related bugs that I've fixed over the years amazes me > yet ignores DST Uhm, you do know that you're supposed to use a neutral timezone (Such as UTC) internally in your code / schema, and convert to local time in the UI? The bugs that I've hit generally have to do with using local time accidentally when UTC is expected. > because every single developer has moved clocks back and forth twice a year for their entire lives WTF? Every single developer knows that their database schema should be in UTC and thus immune to DST issues.
- e28eta 3y ago
  It sounds like you’re ignoring the fact that sometimes programs want to do things based on the user’s current time, and there _are_ reasons for developers to need to be aware of DST and handle edge cases correctly. I inherited some code that was sending push notifications to users with a daily summary. I don’t remember why it was tripping over DST, since the notifications were at a “reasonable” hour (9am?) and afaik the time change happens during the hours most people are asleep, but the ruby API being used had errors for “there are zero / two times that match the time you asked for”. I had to scratch my head for a little on why we were seeing both the zero and two errors in September / October, despite being intellectually well aware that the southern hemisphere seasons are the opposite of the northern.
  - takinola 3y ago
    But using UTC solves that problem, no? The time only changes in DST but not in UTC. If the code checks the time against UST, it will never trip up. Anyways, the only real solution for managing time is to use a library like Luxon so you can stop thinking about it. Time is like cryptographic encryption - Don't roll your own solution if there is a battle tested library available.
    - recursive 3y ago
      It does not. I've got a specification that all inputs and outputs are in local time. Sometimes the timezone isn't known yet. Or at all.
_kst_ 3y ago
That should only matter if times are stored and sorted as local time. Storing time as UTC (e.g. seconds since 1970) and computing local time from that and the current time zone should avoid DST-related bugs.
- andreareina 3y ago
  Until you deal with the future. If I have a recurring 2 pm meeting, I'd be a little put out if some of those suddenly became 3 pm because of a DST change.
jonathanlydall 3y ago
> because every single developer has moved clocks back and forth twice a year for their entire lives Where I live, South Africa, we have a single timezone which never has DST. It is very easy for a developer here to be oblivious of time zones/DST as in practice it will never bite them in the local only market. Well, I lie, it’s only almost never, a common smell of incorrect time handling is when the deployment instructions have a note to ensure the server is set to the correct time zone. Tangental pet peeve of mine, in the early 2000s I received an abuse report with quoted logs with the timestamps being qualified as merely EST (or some other US time zone), which I found super annoying as I had to look up what the offset for such time zone was and then manually apply conversions before I could do any investigating of my own.

WirelessGigabit 3y ago

Oh the joys of living in Arizona! Not having to deal with confusion twice per year! Not having to deal with these sort issues! Or so I thought. All calendar invites I own are set in Arizona time, so for everybody else they shift. Queue the rescheduling requests. For the ones I don't own it actually is better for me as they all shift an hour later.

aljarry 3y ago

> time goes backwards is DST Only if you deal with timestamps that don't contain timezone information. With TIMESTAMPTZ in postgres it's transparent, you don't have to do anything specifically to manage DST.

realaleris149 3y ago
Postgres does not store the actual time zone information, it just stores it in UTC. Is a bit counterintuitive but this is how it works [1]. The "with time zone" part is just for parsing and displaying back. When is displayed the value is converted from UTC to the local time in the current timezone which can result in some very interesting discussions :). [1] https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-DATETIME-INPUT-TIME-STAMPS https://www.postgresql.org/docs/current/datatype-datetime.ht...
- aljarry 3y ago
  TIL :) thanks, I misunderstood that part.

loloquwowndueo 3y ago

Every single US developer maybe. In Mexico DST started in 1994 so developers who started before that (hello!) did need some adjustment and operating system support was not a given. There are also countries where DST is not observed or differs from the US yet developers from those countries might be working remotely for a US company, with US developers or needing to accommodate a significant US clientele.

dotancohen 3y ago
I'm not in the US.
gwbas1c 3y ago
DST is common throughout the world: The days that it starts and stops vary, both by locale, and by year. The operating system keeps track of every locale's DST dates, all the way as long as DST has been a thing. When governments change the date, via law changes, the change usually gets passed along in an OS update.
- deleted 3y ago
  [deleted]
- o11c 3y ago
  Note that Windows has major bugs here - from memory, it only keeps track of the 2 most recent DST rules, so historical timestamps will be wrong after the rules change twice.
- pritambaral 3y ago
  Reporting from India here. No DST ever. I still know what DST is and how it works, but I've never had to change clocks due to DST.
- mook 3y ago
  Looking at the Wikipedia article, it looks like it's not that popular in Asia and Africa. Lots of places seems to have observed it at some point in the past, though a lot of them seem to have been last century. https://en.m.wikipedia.org/wiki/Daylight_saving_time_by_country https://en.m.wikipedia.org/wiki/Daylight_saving_time_by_coun...

gwbas1c 3y ago

> The amount of DST-related bugs that I've fixed over the years amazes me > yet ignores DST Uhm, you do know that you're supposed to use a neutral timezone (Such as UTC) internally in your code / schema, and convert to local time in the UI? The bugs that I've hit generally have to do with using local time accidentally when UTC is expected. > because every single developer has moved clocks back and forth twice a year for their entire lives WTF? Every single developer knows that their database schema should be in UTC and thus immune to DST issues.

e28eta 3y ago
It sounds like you’re ignoring the fact that sometimes programs want to do things based on the user’s current time, and there _are_ reasons for developers to need to be aware of DST and handle edge cases correctly. I inherited some code that was sending push notifications to users with a daily summary. I don’t remember why it was tripping over DST, since the notifications were at a “reasonable” hour (9am?) and afaik the time change happens during the hours most people are asleep, but the ruby API being used had errors for “there are zero / two times that match the time you asked for”. I had to scratch my head for a little on why we were seeing both the zero and two errors in September / October, despite being intellectually well aware that the southern hemisphere seasons are the opposite of the northern.
- takinola 3y ago
  But using UTC solves that problem, no? The time only changes in DST but not in UTC. If the code checks the time against UST, it will never trip up. Anyways, the only real solution for managing time is to use a library like Luxon so you can stop thinking about it. Time is like cryptographic encryption - Don't roll your own solution if there is a battle tested library available.
  - recursive 3y ago
    It does not. I've got a specification that all inputs and outputs are in local time. Sometimes the timezone isn't known yet. Or at all.

_kst_ 3y ago

That should only matter if times are stored and sorted as local time. Storing time as UTC (e.g. seconds since 1970) and computing local time from that and the current time zone should avoid DST-related bugs.

andreareina 3y ago
Until you deal with the future. If I have a recurring 2 pm meeting, I'd be a little put out if some of those suddenly became 3 pm because of a DST change.

jonathanlydall 3y ago

> because every single developer has moved clocks back and forth twice a year for their entire lives Where I live, South Africa, we have a single timezone which never has DST. It is very easy for a developer here to be oblivious of time zones/DST as in practice it will never bite them in the local only market. Well, I lie, it’s only almost never, a common smell of incorrect time handling is when the deployment instructions have a note to ensure the server is set to the correct time zone. Tangental pet peeve of mine, in the early 2000s I received an abuse report with quoted logs with the timestamps being qualified as merely EST (or some other US time zone), which I found super annoying as I had to look up what the offset for such time zone was and then manually apply conversions before I could do any investigating of my own.