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

21–30 of 334 posts

Re: Timezone Bullshit

#21

Post by rbanffy »

bob1029 wrote: post #5

The only situation where our datetime instances deal with timezones is on a one way trip to a user's display, document or email. If you are playing around with parsing timezone strings, you are probably making a huge mistake unless you are parsing someone else's trash data. I feel the standard interchange format for datetimes really should be 64 bit Unix timestamps. These are trivial to store in any database as a nat…

> Trying to carry timezone information around is a mistake.

No.

If a human says a recurring meeting happens at 9 AM Pacific time and the following week they are in daylight saving time, it'll still happen at 9 AM local time. Preserving intent is crucial in this case.

Re: Timezone Bullshit

#22

Post by soco »

stefan_ wrote: post #14
soco wrote: post #11

Earlier quoted context omitted.

The GUI elements should have nothing to do with storing and interchanging timestamps. What you display can query the browser timezone to make it look nice, then send it down converted, over.

Ding ding ding, we got a winner. No, absolutely do not query the timezone once then "convert" (aka remove) the information. Timezones change all the time .

There's a (fresh) extensive comment right above mine which explains the 4 different use cases for dates and the very minimal real need of TZ, let's all read it. Sorry I cannot comment otherwise your arguments because you didn't offer any.

Re: Timezone Bullshit

#23

Post by user-the-name »

stefan_ wrote: post #14
soco wrote: post #11

Earlier quoted context omitted.

The GUI elements should have nothing to do with storing and interchanging timestamps. What you display can query the browser timezone to make it look nice, then send it down converted, over.

Ding ding ding, we got a winner. No, absolutely do not query the timezone once then "convert" (aka remove) the information. Timezones change all the time .

And if the timezone changes, should the meeting you booked at 9 AM now happen at 8 AM?

Re: Timezone Bullshit

#24

Post by soco »

sdm wrote: post #9

> There are actually two timezones that are canonically named "CST", and they're 14 hours apart! Yup. If you say CST do you mean China Standard Time or Central Standard Time? The answer will depend on where you live in the world. There are others that share the same abbreviation as well. But CST is the one that constantly causes trouble in daily life. Just say no.

According to Wikipedia there are more than one overlappings: https://en.wikipedia.org/wiki/List_of_time_zone_abbreviation...

Re: Timezone Bullshit

#25

Post by WatchDog »

levosmetalo wrote: post #16
bob1029 wrote: post #5

The only situation where our datetime instances deal with timezones is on a one way trip to a user's display, document or email. If you are playing around with parsing timezone strings, you are probably making a huge mistake unless you are parsing someone else's trash data. I feel the standard interchange format for datetimes really should be 64 bit Unix timestamps. These are trivial to store in any database as a nat…

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.

Re: Timezone Bullshit

#26

Post by tallanvor »

detaro wrote: post #13
bob1029 wrote: post #5

The only situation where our datetime instances deal with timezones is on a one way trip to a user's display, document or email. If you are playing around with parsing timezone strings, you are probably making a huge mistake unless you are parsing someone else's trash data. I feel the standard interchange format for datetimes really should be 64 bit Unix timestamps. These are trivial to store in any database as a nat…

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.

Re: Timezone Bullshit

#27

Post by jwalton »

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 USA and Canada have been toying with the idea of dropping daylight savings time, so it’s very possible at some point in the future that 6:00pm on July 1st will be EDT in America/New York, but EST in America/Montreal (or vice versa). This is already true for CST - Saskatchewan doesn’t use DST. And there have been times where one country or another changes the start date or end date of DST too, so there’s no reason to assume those will always be the same between Canada and the US.

Re: Timezone Bullshit

#29

Post by juddgaddie »

'There is no good reason to use short timezone codes like EST, CST, PST — doing so will only bring you pain. Either use the tzdb name like America/New_York, or use an offset from UTC, depending on what you want.'

All you need to read/remember is this, this applies everywhere not just with date.

Re: Timezone Bullshit

#30

Post by kenniskrag »

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

Post reply on HN