Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

tomeraberba.ch

Post reply on HN
Print view View original

21–30 of 65 posts

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

#21

Post by boopdewoop »

bigiain wrote: post #19
Moru wrote: 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…

Why not just use epoch? render it however you like. - Posted at 1724222105

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

#22

Post by ajennings »

This reminds me of a bug I created where the calendar showed only 30 days in March. I took the number of hours in the month, divided by 24, and rounded down.

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.

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

#23

Post by lionkor »

boopdewoop wrote: post #21
bigiain wrote: post #19

Earlier quoted context omitted.

> 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…

Why not just use epoch? render it however you like. - Posted at 1724222105

I prefer human readable datetime for debugging, because there are a lot of programs which have timings and timeouts for certain operations. Being able to quickly observe that a timeout happened in 500 ms instead of 1.5s would be interesting, epoch does not show you this information.

Similar with quickly jumping to a certain day.

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

#24

Post by maxglute »

Moru wrote: 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.

Yeah I wish all time is given in some standardized iso/unix time and then have user reformat depending on on browser or OS settings.

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

#25

Post by Aardwolf »

stephen_g wrote: post #6
Moru wrote: 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.

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!

I also hate "1 year ago" when it was actually 23 months ago

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

#26

Post by mjtardiff »

Keep time and calculate intervals in epoch time, for sure. But the DST/ST switch happens at 02:00 local time on the date of the switch (always a Sunday morning in the US), and so since the OP points out that the bug only happens when DST switches at 23:00 PT…that’s why. The code was doing time-switching wrong in all zones.

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.

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

#27

Post by saagarjha »

mulmen wrote: post #7

I’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.

Googlers are not all timekeeping experts, nor are they all capable of summoning that knowledge at all times when writing code.

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

#28

Post by Dylan16807 »

crote wrote: post #13
mulmen wrote: post #7

I’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.

No, it isn't. That approach works fine for things like logging where are your timestamps are in the past, but the moment you have to deal with future timestamps it leads to some truly horrible issues when some political leader decides to change the definition of the timezone. Suddenly all your future epoch-based datetimes are representing the wrong wall clock time...

But the context of the article was logging and purely a display issue.

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

#29

Post by [deleted] »

Moru wrote: 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.

[deleted]

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

#30

Post by Dylan16807 »

lionkor wrote: post #23
boopdewoop wrote: post #21

Earlier quoted context omitted.

Why not just use epoch? render it however you like. - Posted at 1724222105

I prefer human readable datetime for debugging, because there are a lot of programs which have timings and timeouts for certain operations. Being able to quickly observe that a timeout happened in 500 ms instead of 1.5s would be interesting, epoch does not show you this information. Similar with quickly jumping to a certain day.

> Being able to quickly observe that a timeout happened in 500 ms instead of 1.5s would be interesting, epoch does not show you this information.

1724222105000 and 1724222105.000000 are common forms that solve that problem.

Post reply on HN