The 1 Hour per Year Bug, but only in Pacific time
tomeraberba.ch
The 1 Hour per Year Bug, but only in Pacific time
1–10 of 65 posts
Re: The 1 Hour per Year Bug, but only in Pacific time
#2Can 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.
Re: The 1 Hour per Year Bug, but only in Pacific time
#3> Normally I would have dismissed that as a coincidence, but daylight saving time also ended at 11:00pm (PT) on November 7!
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)?
Re: The 1 Hour per Year Bug, but only in Pacific time
#4The 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?
Re: The 1 Hour per Year Bug, but only in Pacific time
#5Can 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.
Yeah at least I want a mouseover to see the real timestamp, and the column to be sortable.
Re: The 1 Hour per Year Bug, but only in Pacific time
#6Can 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.
The absolute worst are ones like “last month”, “last week” or “earlier this week” - almost absolutely useless! Especially for logs of things that happened at work, I extremely frequently want to know the day and date something happened, but that style obscures that sometimes to the point where you can’t even tell which week it was!
Re: The 1 Hour per Year Bug, but only in Pacific time
#7I’m having a hard time following how such naive time handling became part of a Google product. Pick an epoch for timekeeping. Timezones are a display issue.
Re: The 1 Hour per Year Bug, but only in Pacific time
#8Can 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.
I agreed I have gone so far as to replace strings in HTML with the date in the tag, but it is not always available in that tag especially now with Javascript frameworks taking over. Further your wording makes it clear to me why date formatting is hard, what is most significant is clearly subjective.
Re: The 1 Hour per Year Bug, but only in Pacific time
#9It does make me wonder how many bugs like these exist in the average codebase. In this case there was an "unusually large" amount of reports, all coming from the same timezone, all filed at the same time.
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?
Re: The 1 Hour per Year Bug, but only in Pacific time
#10> Normally I would have dismissed that as a coincidence, but daylight saving time also ended at 11:00pm (PT) on November 7! 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)?
This is my understanding as well. and and Wikipedia backs me up on it [https://en.wikipedia.org/wiki/Pacific_Time_Zone#Daylight_tim...].
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.