Live data from Hacker News

The 1 Hour per Year Bug, but only in Pacific time

tomeraberba.ch

31–40 of 65 posts

Re: The 1 Hour per Year Bug, but only in Pacific time

#31
post #19
post #2

Can we talk about all the problems with dates formated as "today", "tomorrow" or "2 hours ago" when trying to figure out how far apport two log-events happened? I at least want an OPTION to set that I want all dates down to the second exactly when they happened... And in a standard format with Y-M-D H:m:s that can sort naturally. The most significant part first, the least significant last.

> in a standard format with Y-M-D H:m:s 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…

https://ijmacd.github.io/rfc3339-iso8601/

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.

Re: The 1 Hour per Year Bug, but only in Pacific time

#32

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.

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?

Re: The 1 Hour per Year Bug, but only in Pacific time

#33
post #4

The article claims that the daylight savings transition happens at 11pm in pacific time. However, my understanding is that this transition should happen at 2 am for all us time zones. Where is 11pm coming from?

Towards the bottom, it states:

  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.

Re: The 1 Hour per Year Bug, but only in Pacific time

#36
post #35

I once came across a similar bug in a popular JS lib, only in Russian timezones, only in some browsers, only on Windows. (It happened due to Russia changing their timezones). https://github.com/yui/yui2/pull/15

Makes sense since the Russians have been fiddling with time and seems to have turned it back to 1962.

Re: The 1 Hour per Year Bug, but only in Pacific time

#37
post #4

The article claims that the daylight savings transition happens at 11pm in pacific time. However, my understanding is that this transition should happen at 2 am for all us time zones. Where is 11pm coming from?

Towards the bottom, it states: 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 t…

[deleted]

Re: The 1 Hour per Year Bug, but only in Pacific time

#38
post #4

The article claims that the daylight savings transition happens at 11pm in pacific time. However, my understanding is that this transition should happen at 2 am for all us time zones. Where is 11pm coming from?

Yeah, even the Wikipedia article the article links to claims that the transition's at 2AM:

> 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).

Re: The 1 Hour per Year Bug, but only in Pacific time

#39
post #4

The article claims that the daylight savings transition happens at 11pm in pacific time. However, my understanding is that this transition should happen at 2 am for all us time zones. Where is 11pm coming from?

DST is 2am in Pacific time zone. The article doesn’t make much sense.

Re: The 1 Hour per Year Bug, but only in Pacific time

#40
post #4

The article claims that the daylight savings transition happens at 11pm in pacific time. However, my understanding is that this transition should happen at 2 am for all us time zones. Where is 11pm coming from?

Towards the bottom, it states: 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 t…

The article may state it, but it's not true. US DST starts and ends at 2am in every time zone. It doesn't start at 2am in the east, 1 central, 12 west, 11 pacific.
Post reply on HN