Live data from Hacker News

Timezone Bullshit

blog.wesleyac.com

61–70 of 334 posts

Re: Timezone Bullshit

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

> I feel the standard interchange format for datetimes really should be 64 bit Unix timestamps.

UNIX timestamps are ambiguous.

ISO 8601 is perfectly good interchange format.

Re: Timezone Bullshit

#62
post #35

Earlier quoted context omitted.

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.

What do you have to implement?

The EU is currently one timezone for most of its area, the whole continent excluding Portugal (edit: and Finland, Greece, Baltic states) has the same timezone. But actually it should be 3 or 4 timezones if you want to be close to solar time. Also, there are people who would prefer having solar zone time +1 (so e.g. UTC+2 in Germany instead of UTC+1). The EU decided to chicken out and let the members decide for themselves. So now each country has to decide which timezone it would like to implement, and of course if a neighbour does it differently, you also got yourself a timezone boundary at your border, which people dislike. So now all the politicians are caught in a state of indecision, keeping the status quo.

Re: Timezone Bullshit

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

In some cases, storing times in UTC opens you up to possible errors:

https://codeofmatt.com/on-the-timing-of-time-zone-changes/

I think the right thing is to store times with the timezone the user wanted when they created the time. You can often use defaults or other UX niceties to streamline specifying TZ, but not always.

Also, if you'll want to unambiguously know the timestamp's exact point in time at some point (like for comparison with other dayetimes), you should save the offset from UTC alongside the actual datetime. Otherwise, around clock changes like "fall back" you cannot tell if you're seeing 2 AM for the first or second time.

This is the best I've come to trying to piece datetime storage together. If someone has better advice, I'd love to hear it.

For more of my theory on timezone handling and the sources I've used to help me think it through, see http://howicode.nateeag.com/dates-and-times.html .

Re: Timezone Bullshit

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

On the topic of DST... can you explain why some countries use DST? Anytime I look for the reasoning of it, it says that DST helps "make better use of daytime" but how? The earth isn't gonna say "Damn! These people changed their clocks. I better change by rotation and give them more sun time." Whether you have DST or not, you still have the same amount of time with sunlight in a day.

Because of the unfortunately still common 9-to-5 work schedule.

Re: Timezone Bullshit

#66

Earlier quoted context omitted.

The infuriating thing is that our solution to this is to change the clock instead of just changing our schedules. It's completely ridiculous.

...no, actually it’s extremely logical. Changing clocks society wide is far easier than getting every single person and company to adjust its schedule.

Perhaps it was easier in the times before the internet. Now a consistent timeline should be far more convenient than not having to change your habits by a little bit.

Edit: If changing schedule is normalized, then it would be just as convenient as changing the clock. In countries without DST, if someone started using DST instead of changing their own schedule, it would be just as difficult.

Re: Timezone Bullshit

#67
post #55

Earlier quoted context omitted.

It will not happen. The science is overwhelming that having one timezone all year long is worse for people, and switching the clock back and forth twice a years is a minor nuisance at most. The EU's "Ban DST" is the same populist bullshit as Trumps "inject Windex to cure COVID". Based on nothing and ignorant at best. And the cherry on top is, if you ask the EU if they want to receive a no strings attached gift of €10…

If the science is overwhelming, do you have a source? If not, what are the downsides to having the same timezone all year?

Never heard about windex. Now I know.

Re: Timezone Bullshit

#68
post #34

Earlier quoted context omitted.

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

Surprisingly, a bunch of software doesn't like it when you setup TAI, if you manage it to begin with.

Re: Timezone Bullshit

#69
post #54

It's not just timezones names that are bullshit (they are!), the whole calendar is dumb. Ideally the world should switch to an "earth calendar" where the year begins on the shortest day (currently Dec 21st for 90% of the population) and there are four yearly planet-wide holidays: 1. northern solstice 2. southern solstice 3. northward equinox 4. southward equinox While we are at it, we could also do something more cle…

Part marketing ploy, part genuine attempt to improve time systems, especially in a global context, Swatch actually once tried to do so: https://en.m.wikipedia.org/wiki/Swatch_Internet_Time

Unfortunately, .beat time didn’t catch on.

Re: Timezone Bullshit

#70
post #36
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…

To be pedantic EST and EDT are offsets. America/New_York is the timezone which consists of multiple offsets that depends on the time of year and date mostly determined by the local civil authority. For example in 2005, the US extended daylight saving time by four weeks. This difference between 2004 and 2006 is a part of the timezone.
Post reply on HN