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

51–60 of 65 posts

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

#51

Post by toast0 »

mannykannot wrote: post #49
mattbillenstein wrote: post #14

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.

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…

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.

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

#52

Post by russdill »

mattbillenstein wrote: post #14

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.

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

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

#53

Post by toast0 »

mulmen wrote: post #17
crote wrote: post #13

Earlier quoted context omitted.

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.

Storing epochs for future times that are specified in local time usually isn't enough considering that local time zones change. If you only deal in times and time zones where time zone changes are announced far enough in advance that zone changes can be processed before any events they effect are in the system, it doesn't matter. But if people schedule things years out in countries with reasonable notice, or weeks out in countries where there's a lack of notice, there's a good chance of doing things wrong.

To accomidate these future dates, you should store the localtime and you should also store the offset and/or an epoch determined at time of storage. When rules change, you should evaluate future events and for events where the calculated epoch changes, storing and using the new epoch is a sensible default --- you should ideally show the user a summary of changes, so they can adjust if they have things that were entered in local time for convenience but are actually scheduled in a different zone.

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

#54

Post by apple4ever »

Aardwolf wrote: post #25
stephen_g wrote: post #6

Earlier quoted context omitted.

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

Oh yeah I've run into that a bunch too. The problem is they don't want to do "1.5 years ago" or something like that, and the rounding is really bad.

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

#55

Post by mulmen »

hansvm wrote: post #47
mulmen wrote: post #17

Earlier quoted context omitted.

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.

That's the same kind of mentality that kept Google Calendar from being able to schedule a monthly meeting on the last day of the month. If you scheduled it on the 31st, the tool would happily accept that 5 months each year wouldn't have your monthly meeting. Suppose I have an 8am alarm to wake up in the morning. I want that to happen once per day in my current local timezone. If I change locations, the epoch I'm bein…

That’s the difference between the 31st and the last day of the month. It’s a UX issue, not a timekeeping issue.

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

#56

Post by LorenPechtel »

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!

Most of the time it's the human-friendly version. The detail should be available, though.

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

#57

Post by russdill »

yuliyp wrote: post #42

My favorite DST bug was a system that was supposed to run every few seconds taking a nap for an hour. It was an event loop thingy that had a few different types of tasks it might do. When it finished one of those tasks it'd record (in time-zone-local time) the time it completed it. When the event loop ran, it'd check that timestamp against now to see whether the task needed doing. In comes the DST rollback. At 1:59 A…

All such delays should be done uses monotonic clocks. This simplistic solution runs still into problems when you have long delays, especially if the system suspends and/or power cycles. Or if you want the interval to always expire at some wall clock aligned time, such as every half hour on the half hour.

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

#58

Post by johnisgood »

tonyhart7 wrote: post #44
Aardwolf wrote: post #25

Earlier quoted context omitted.

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

this is what I hate about youtube, when you look at the title and says 1 year ago and its just 1 month away for 2 years lol

At least it gives you the date when you hover over with your cursor.

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

#59

Post by mulmen »

saagarjha wrote: post #27
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.

It just seems like something Google would have solved in a general sense. It’s a hard problem, asking everyone to get it right is unrealistic, clearly.
Post reply on HN