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

11–20 of 334 posts

Re: Timezone Bullshit

#11

Post by soco »

netsharc wrote: post #6
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…

Hmm, your applications don't have user input asking for a time?

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.

Re: Timezone Bullshit

#12

Post by kstenerud »

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…

It's not quite so cut-and-dry. UNIX timestamps unfortunately don't solve the problems of time because they don't contain enough information.

Time is something that developers get wrong more often than any other type. Your time data requirements change as your use case for the time changes.

From https://github.com/kstenerud/compact-time/blob/master/compac...

Aside from issues of synchronization, leap seconds, data container limitations and such, it's important to choose the correct kind of time to store, and the right kind depends on what the purpose of recording the time is.

There are three main kinds of time:

*Absolute Time*

Absolute time is a time that is fixed relative to UTC (or relative to an offset from UTC). It is not affected by daylight savings time, nor will it ever change if an area's time zone changes for political reasons. Absolute time is best recorded in the UTC time zone, and is mostly useful for events in the past (because the time zone is now fixed at the time of the event, so it probably no longer matters what specific time zone was in effect).

*Fixed Time*

Fixed time is a time that is fixed to a particular place, and that place has a time zone associated with it (but the time zone might change for political reasons in the future,for example with daylight savings). If the venue changes, only the time zone data needs to be updated. An example would be an appointment in London this coming October 12th at 10:30.

*Floating Time*

Floating (or local) time is always relative to the time zone of the observer. If you travel and change time zones, floating time changes zones with you. If you and another observer are in different time zones and observe the same floating time value, the absolute times you calculate will be different. An example would be your 8:00 morning workout.

*When to Use Each Kind*

Use whichever kind of time most succinctly and completely handles your time needs. Don't depend on time zone information as a proxy for a location; that's depending on a side effect, which is always brittle. Always store location information separately if it's important.

Examples:

Recording an event: Absolute

Log entries: Absolute

An appointment: Fixed

Your daily schedule: Floating

Deadlines: Usually fixed time, but possibly absolute time.

Re: Timezone Bullshit

#13

Post by detaro »

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

Re: Timezone Bullshit

#14

Post by stefan_ »

soco wrote: post #11
netsharc wrote: post #6

Earlier quoted context omitted.

Hmm, your applications don't have user input asking for a time?

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.

Re: Timezone Bullshit

#15

Post by seszett »

soco wrote: post #11
netsharc wrote: post #6

Earlier quoted context omitted.

Hmm, your applications don't have user input asking for a time?

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.

You cannot convert a time string in the future to a timestamp. You must keep it as a string with timezone information until the time actually comes.

Re: Timezone Bullshit

#16

Post by levosmetalo »

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.

Re: Timezone Bullshit

#17

Post by c0l0 »

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/golang/go/issues/9617), which, at least for Elastic's filebeat, seem to vary at runtime depending on whether or not you have a time zone database available...

Moral of the story: Please just conform to ISO-8601 everywhere.

Re: Timezone Bullshit

#19

Post by messe »

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.

As a support engineer living in Dublin “IST” is the bane of my life.

Re: Timezone Bullshit

#20

Post by de_Selby »

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.
Post reply on HN