The 1 Hour per Year Bug, but only in Pacific time
tomeraberba.ch
tomeraberba.ch
Make sure that has a timezone (or better still, is explicitly in UTC).
Also, bytes are cheap these days, let's have millisecond precision seconds there too.
Lets go full ISO 8601 and use yyyy-mm-ddThh:mm:ss.sssZ at least this way you have a recognised standard to appeal to if some other code or library can't parse your datetimes.
(One reason I'd accept _not_ using ISO8601 dates is if your database uses a datetime format that's equally human readable and unambiguous, MySQL users might use YYYY-MM-DD hh:mm:ss or YYYY-MM-DD hh:mm:ss.sss with an assumed and well documented UTC timezone.)
Similar with quickly jumping to a certain day.
1724222105000 and 1724222105.000000 are common forms that solve that problem.
RFC3339 allows (space) to replace the T, which is about 1000 times more readable for a human.
ISO8601 and RFC3339 both agree the time part of should include E.G. a Z for the Zulu (UTC) timezone abbreviation.
I'm of the mindset that unspecified timezones (the MySQL format mentioned YYYY-MM-DD hh;mm:ss etc) are 'undefined behavior' and therefore context dependent. For user facing applications they should be the local 'normal persons' timezone, while for operator (E.G. SQL console) and programmed interface facing tasks should be either UTC of TAI time, as expected by the system.
But as another poster points out, when a server lives in one time zone and is used in another, all hell can easily break loose when deciding what to show the local user.
But imagine getting a single bug report, which doesn't provide a timezone or timestamp and essentially boils down to "I swear it said the wrong date yesterday but it fixed itself!": how much time are you really going to spend trying to reproduce it before closing it with the conclusion that the user was probably just imagining things?
The Temporal spec[1] should alleviate a lot of the JS induced pain. Knowing how to correctly store and manipulate time data, however is a completely separate issue that even really experienced engineers can easily mess up, even with solid STD lib support.
[1] https://www.nist.gov/pml/time-and-frequency-division/popular...
[2] At present, daylight saving time in the United States begins at 2:00 a.m. on the second Sunday of March (at 2 a.m. the local time time skips ahead to 3 a.m. so there is one less hour in that day) [and] ends at 2:00 a.m. on the first Sunday of November (at 2 a.m. the local time becomes 1 a.m. and that hour is repeated, so there is an extra hour in that day.)
2 am local time is the transition time. Some days you go from 1:59 am standard to 3:00 am daylight, others you go from 1:59 am daylight to 1:00 am standard.
It's not like leap seconds which are added (or hypothetically removed) at a specific universal time, so whatever your time zone, whatever minute corresponds with utc 23:59 gets an extra second.
The bigger problem was that I couldn't replicate it because I was in Arizona (which doesn't observe DST). Only users outside of Arizona were seeing the bug.
Huh? Unless I'm mistaken, Daylight Saving ended at 2am local time on Nov 7, 2021.
Was the bug that Day Saving is internally set based on Eastern Time (i.e. 2am ET / 11pm PT)?
Some of the software I've written _explicitly_ disables scheduling mobile notifications during the transition periods so I was also very confused by that. Your ET speculation makes sense to me. I'll bet that whatever server/containers being used for the backend were running in the Eastern Timezone.
Or it is just assuming a standard offset, not taking into account the 6 hours a year where eastern and western time isn't 3 hours apart
In comes the DST rollback. At 1:59 AM Pacific Daylight time the task ran. At 2:00 AM Pacific Daylight time the time changes to 1:00 AM Pacific Standard time. For the next hour it just sees "ooh 1:01 AM is not more than 1 minutes after 1:59 AM, I'm going to sleep. 1:02 AM is not more than 1 minute after 1:59 AM..." and ends up falling behind for that hour until it magically fixes itself at 2:01 AM Pacific Standard Time
Suppose I have an 8am alarm to wake up in the morning. I want that to happen once per day in my current local timezone. If I change locations, the epoch I'm being alarmed at should change. If I travel quickly enough to experience multiple 8ams, I only want one of them (the first one). If laws change to give me multiple 8ams in a single locale, it's ambiguous which one I want. How your alarm app handles that varies, but you should do _something_ (flag the situation in the app, pick one (if one of them is about the same epoch as the previous alarm, maybe pick that one), ...).
For calendars you have probably a different set of choices. If all participants are in the same time zone, you probably want the meeting to move as regulations change the definition of 8am. If they're in different time zones which all practice daylight savings and the meeting doesn't conflict with any of the 1-2am haunted hours then the meeting should probably move with daylight savings, reference the local time as it was defined when the meeting was created, and not move as some dictator redefines a time zone (becoming a cross between a display issue and actually considering local time). If you don't know anything as a calendar app about the participants, there will be edge cases where you make bad decisions, so you either accept that or flag the ambiguity when appropriate.
And so on.
If we can convince everyone to switch to some kind of atomic time without leap seconds I'd be tickled pink. That's not the world we live in though.
To accomidate these future dates, you should store the localtime and you should also store the offset and/or an epoch determined at time of storage. When rules change, you should evaluate future events and for events where the calculated epoch changes, storing and using the new epoch is a sensible default --- you should ideally show the user a summary of changes, so they can adjust if they have things that were entered in local time for convenience but are actually scheduled in a different zone.
Unnecessarily negative IMHO to implicitly call the person who came before you a clown, especially for a bug which is so trivial.
It turns out that the Pacific Time Zone is the only one where the bug caused a user visible difference because:
1. Daylight saving time starting or ending changes the time zone offset by just one hour.
2. The bug only has an effect when the difference in the number of hours goes from less than a day to at least a day, or vice versa (e.g. 23 to 24 or 24 to 23).
The only hour of the day that satisfies those two conditions is 11:00pm, and the only time zone where daylight saving time starts and ends at 11:00pm is the Pacific Time Zone.> North America coordination of the clock change differs, in that each jurisdiction changes at each local clock's 02:00, which temporarily creates an imbalance with the next time zone (until it adjusts its clock, one hour later, at 2 am there).