3 ms·

Clocks roll back at 2am Pacific time just like everywhere else - so the author's explanation seems unsatisfying although I've encountered this type of bug befor

Clocks roll back at 2am Pacific time just like everywhere else - so the author's explanation seems unsatisfying although I've encountered this type of bug before.

mjevans 2y ago
Yeah, as soon as they said 11PM I realized, ` they're using EST as the timezone? ` which would just do it at that time for everyone using the doc? I don't work with raw date objects in JavaScript very much, is that illogical behavior from it's Date object?
- cpfohl 2y ago
  It’s totally feasible; if the server is using JS and is located in ET the parsed Date tends to be converted internally to local zone (very frustrating). 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://tc39.es/proposal-temporal/docs/ https://tc39.es/proposal-temporal/docs/
cortesoft 2y ago
Yeah, I was waiting for the author to mention the unstated premise that the software was using Eastern time as the default.
mannykannot 2y ago
I thought the same, but I was not sure, so I searched for the answer, and surely the NIST page "Daylight Saving Time Rules" [1] would be definitive? Unfortunately, its statement of the rule [2] seems ambiguous, in that it uses '2 a.m.' without qualifying it as local time (though the example does.) Is there a rule saying that times expressed as a.m. (or p.m., I suppose) are always local time (in whatever context they appear, which could also be a cause of ambiguity) unless explicitly qualified otherwise? [1] https://www.nist.gov/pml/time-and-frequency-division/popular-links/daylight-saving-time-dst 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.)
- toast0 2y ago
  The parenthetical makes the statement clear. 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.
russdill 2y ago
I sense the author has a myriad of false assumptions about timezones left to be discovered in their codebase.

Clocks roll back at 2am Pacific time just like everywhere else - so the author's explanation seems unsatisfying although I've encountered this type of bug before.

mjevans 2y ago

Yeah, as soon as they said 11PM I realized, ` they're using EST as the timezone? ` which would just do it at that time for everyone using the doc? I don't work with raw date objects in JavaScript very much, is that illogical behavior from it's Date object?

cpfohl 2y ago
It’s totally feasible; if the server is using JS and is located in ET the parsed Date tends to be converted internally to local zone (very frustrating). 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://tc39.es/proposal-temporal/docs/ https://tc39.es/proposal-temporal/docs/

cortesoft 2y ago

Yeah, I was waiting for the author to mention the unstated premise that the software was using Eastern time as the default.

mannykannot 2y ago

I thought the same, but I was not sure, so I searched for the answer, and surely the NIST page "Daylight Saving Time Rules" [1] would be definitive? Unfortunately, its statement of the rule [2] seems ambiguous, in that it uses '2 a.m.' without qualifying it as local time (though the example does.) Is there a rule saying that times expressed as a.m. (or p.m., I suppose) are always local time (in whatever context they appear, which could also be a cause of ambiguity) unless explicitly qualified otherwise? [1] https://www.nist.gov/pml/time-and-frequency-division/popular-links/daylight-saving-time-dst 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.)

toast0 2y ago
The parenthetical makes the statement clear. 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.

russdill 2y ago

I sense the author has a myriad of false assumptions about timezones left to be discovered in their codebase.