Hacker News Reader

Comment by chrchr | Hacker News Reader

It's really not that difficult compared to what we have now. In our current system, there's one hour a year that happens twice and one that gets skipped. It's a weird special case, but we manage.

View on HN

Badly, we manage badly. I have wasted hundreds of hours debugging. Other people's code and writing involved workarounds because the team couldn't resist using "standard" ISO timestamps instead of the much more "arrow of time" like numeric offset (like Unix time)...

How are iso timestamps a problem? You need a time zone of course. Usually people stick to UTC. But it's trivial to convert iso timestamps to unixtime so it's hard to imagine how one would have more bugs.

> How are iso timestamps a problem? You need a time zone of course.

You answered your own question in the following sentence - ISO 8601 timestamps do not require a time zone, and infer "local time" if none is provided.

ISO 8601 timestamps do require a time zone when it is relevant. You can only use non-offset timestamps if "local time" is constant. If your time zone varies, you cannot use non-offset timestamps. Your choices are to choose a single tz and stick to it (in which case offsets should be used to clarify for humans), use UTC (which is probably the simplest option since you're sticking with one tz to begin with) or use offsets properly, marking the current timezone on all of them. Trying to use "local time" in places with DST is like trying to build a bridge out of paper.

For this reason, most people either use UTC time or they use offset timezones for timestamps. The latter is nicer for humans who like understanding when things happened in terms other than hundreds of millions of seconds since 1970, but more complex to implement.

Using standard ISO timestamps is good. The reason why people would like to use them is because they sort well, they parse everywhere, and they're human-readable. That last reason is the main and really only reason why you would prefer it to a Unix timestamp. They're standard, but they're a standard for how to communicate things in a human-readable manner. If you wanted to just store accurate time, store a binary 128-bit fixed-point long instead of using UTF-8, since it doesn't need to be human-readable.

Is there anything in the standard to support what you're saying? Based on [1], the guidance is:

> [5.3.1.1] When the application identifies the need for an expression only of a time of the day then the complete representation shall be a single numeric data element comprising six digits in the basic format, where [hh] represents hours, [mm] minutes and [ss] seconds.

> [5.4.1] The components of a time-point shall be written in the following sequence

> For calendar dates:

> year - month - day - time designator - hour - minute - second - zone designator

> The zone designator is empty if use is made of local time of the day in accordance with [5.3.1.1]

[1] http://lists.ebxml.org/archives/ebxml-core/200104/pdf00005.p...

Yeah, exactly. When there's only a need for time of day then the time is enough. The standard lets you pick the tool you need here, it's not going to have some kind of procedure for determining whether your application should use one thing or not. It's very clear that here that undesignated time stamps are the wrong one. The standard only describes a set of tools, what I said was common sense.However, the information is there. In 5.3.4.1 you have "When it is required to indicate the difference between local time and UTC". When it is required. If your time zone changes it obviously is required.

> That last reason is the main and really only reason why you would prefer it to a Unix timestamp.

I think this sort of argument is a bit shortsighted. Using ISO timestamps brings with it the semantics of including UTC offsets in pretty much every operation and historically date library APIs have had their ways of confusing consumers. Sure you can read the data without having to convert them in troubleshooting. You also will end up troubleshooting more because somebody somewhere used a library call that discarded an offset or something similar.

I had to look up that last bit. There was a system I was working with whose developers told me “Assume Eastern Time” all the time (I'm on PDT/PST)…until the daylight saving time change in March. I missed some data from their end and their developers told me to “just fetch again and correct your code”

> While it may be safe to assume local time when communicating in the same time zone, it is ambiguous when used in communicating across different time zones.

https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators

I love how the time zone designator chapter on Wikipedia also illustrates a common complexity pitfall.

> So the zone designation for New York (on standard time) would be "−05:00"

Except for the other half of the year where it is "-04:00". If you, by chance, pick that offset up in logic, make sure that where you apply it it is still the same half of the year! Classical off by one.

Calendar items that I added a month ago have now shifted by an hour. It's all rather exasperating. Not to mention the three weeks of headache each spring after the change.

Reply on news.ycombinator.com