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

Timezone Bullshit

blog.wesleyac.com

Post reply on HN
Print view View original

31–40 of 334 posts

Re: Timezone Bullshit

#31

Post by jmgao »

jwalton wrote: post #27

Another reason not to use EST/EDT is that they are overspecifying the time zone in most cases. If you ask for output in EDT, but the date is in December (which is not part of daylight savings time) then should the date output be UTC-4 or UTC-5? Technically you asked for EDT. Using EST as a shortcut isn’t a good idea, either - most software will “know what you mean” and use EST or EDT appropriately... except, both The…

> both The USA and Canada have been toying with the idea of dropping daylight savings time

Individual states are toying with the idea as well [1], which presents a problem if one of the tzdata locations decides to change its rules. You're screwed no matter what you choose to do. :-(

1: https://www.syracuse.com/state/2020/11/state-senator-introdu...

Re: Timezone Bullshit

#32

Post by detaro »

tallanvor wrote: post #26
detaro wrote: post #13

Earlier quoted context omitted.

Human-decided events in the future are an obvious example. E.g. "every second Tuesday at 8:00" or "May 17, 2025, 8:00" shouldn't ever happen at 7 or 9, even if your software didn't have accurate DST information for that point available initially (which countries do change, sometimes with only a few weeks of warning!).

What if you're scheduling a meeting for multiple people, and normally you're in Seattle, but for some of these meetings you'll be in New York? You don't want the meeting to be at 8:00 your time because chances are the people in Seattle aren't going to join your call at 5:00 their time.

A meetings timezone can be independent of a users, yes. E.g. the meeting time should be specified as e.g. "8:00 America/Los_Angeles" (or have a location-based lookup, but thats another level of indirection). That way it follows whatever DST rules there are, but your local phone time being in NY time only affects your display.

Re: Timezone Bullshit

#33

Post by phlo »

WatchDog wrote: post #25
levosmetalo wrote: post #16

Earlier quoted context omitted.

And then your application has to schedule a recurring weekly meeting happening at exactly 9:00 CST, and suddenly, you have to update your DB schema and all code instances everywhere to actually deal with the time zones. And then you realize you'd be better off if you were just using a sane time zone library from the start instead of pretending time zones don't exist.

They are different things. You store your datetimes/instants as UTC, you store your "every day at 9 CST" rule separate from that. Your rule table might have a column for a cron expression, and a column for the tz database name. Meanwhile, your table for the meeting records has the time represented as a UTC timestamp.

And to stay with the theme of the article: Chances are, the meeting actually _isn't_ intended to be scheduled for 9am CST, but rather 9am America/Chicago. The key difference being that Chicago only observes CST for half of the year, and most people would probably expect for their recurring meeting to happen at the same local time, regardless of the season.

If the meeting is in _the other_ CST (the Taipei one), there's good news: Taipei doesn't do daylight savings. On the flip side, Chicago attendees might dial in fourteen hours early, so Asia/Taipei is a safer bet, too.

Re: Timezone Bullshit

#34

Post by jnye131 »

de_Selby wrote: post #20
c0l0 wrote: post #17

The problem highlighted here causes one of the few gripes I have with PostgreSQL, and its logging capabilities in particular: It seems to only support logging time in one single format, which does contain a timezone identifier - but using the potentially ambiguous shorthand name. A few moons ago, that led me down a whole new rabbit hole of its own that is Golang's time zone parsing capabilities ( https://github.com/g…

I'd say the moral is that server side should always be in UTC.

OR.. should they be in TAI? https://en.wikipedia.org/wiki/International_Atomic_Time

Re: Timezone Bullshit

#35

Post by Hamuko »

kenniskrag wrote: post #30
jwalton wrote: post #27

Another reason not to use EST/EDT is that they are overspecifying the time zone in most cases. If you ask for output in EDT, but the date is in December (which is not part of daylight savings time) then should the date output be UTC-4 or UTC-5? Technically you asked for EDT. Using EST as a shortcut isn’t a good idea, either - most software will “know what you mean” and use EST or EDT appropriately... except, both The…

> toying with the idea of dropping daylight Europeans turn back clocks for daylight saving, perhaps for last time. source: https://www.dw.com/en/europeans-turn-back-clocks-for-dayligh...

The EU DST debacle has been such a shitshow that I have trouble believing the words "perhaps for last time". And now with COVID-19, I haven't seen anyone actually focus on implementing the damn thing.

Re: Timezone Bullshit

#36

Post by phlo »

jwalton wrote: post #27

Another reason not to use EST/EDT is that they are overspecifying the time zone in most cases. If you ask for output in EDT, but the date is in December (which is not part of daylight savings time) then should the date output be UTC-4 or UTC-5? Technically you asked for EDT. Using EST as a shortcut isn’t a good idea, either - most software will “know what you mean” and use EST or EDT appropriately... except, both The…

> If you ask for output in EDT, but the date is in December (which is not part of daylight savings time) then should the date output be UTC-4 or UTC-5?

EST is always UTC-4 and EDT is always UTC-5. Both of these exist throughout the year. The only change happening in Spring/Autumn is that some places change which time zone they currently observe.

This also addresses the second problem that you outlined. As long as the query is properly specified (if you want information related to a location, use America/New York; if you want information related to a time zone, use the time zone), you can always get an unambiguous and correct answer.

Re: Timezone Bullshit

#38

Post by tal8d »

Many years ago USPS provided a data stream that included every sorting machine operation a mail piece went through, the location it occurred (zip code), and the local time (sans timezone information). That was an absolute nightmare of a project that always had a few weekly cases of letters somehow time-traveling. Also, I was surprised to learn that there are sort facilities on tribal lands - I was not surprised to learn that they elected to record time differently from the state that surrounded them.
Post reply on HN