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

11–20 of 65 posts

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

#11

Post by Moru »

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!

And if you save something and need to look it up a year later it's even less useful. Last week computed from save date? File save date changed because zip-file didn't save the date? Well, now it's worse than useless, now it's missleading.

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

#12

Post by Moru »

crote wrote: post #9

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

This was probably what happened for several years already until this person got curious.

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

#13

Post by crote »

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

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

#15

Post by bigiain »

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 consider those as "management oriented time deltas". Usually specifically requested by Project Managers because they're so imprecise that they can avoid being held responsible for anything...

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

#16

Post by londonlawyer »

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

[dead]

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

#17

Post by mulmen »

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

Timekeeping is always epoch based. When the definition changes you update the display code. There’s no way to write code today that accounts for future changes in local time.

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

#18

Post by andreareina »

pastage wrote: post #8
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.

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.

"Most significant" in this context is in analogy to most significant bit/digit, which is objective. In this case, the year.

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

#19

Post by bigiain »

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

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

#20

Post by andreareina »

jbrot wrote: 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?

Maybe a cross-timezone interaction? 23:00 pacific is 02:00 eastern (most days)
Post reply on HN