Hacker News Reader

Comment by willis936 | Hacker News Reader

Is the timezone necessary to be compliant? My favorite ISO 8601 format is "%Y%M%DT%h%m%s%", but the table includes a "−Z" on the end and the "Now" column evaluates this as my current timezone.

It says the list isn't exhaustive, but I'm just curious how often others actually embed the timezone rather than just passing around UTC.

View on HN

If you're looking in the backwards direction and its important what local time in a different location it happened, that's the use case for offset date time. Maybe you're investigating traffic patterns in which case it can be clearer when it's 6pm local time rather than noon utc or whatever. Embedding that in the returned timestamp can save another field.

However, for the forward looking/scheduling one one, if you want it to keep the same time across timezone/DST policy changes, you need to the full on timezone designator (i.e. America/New_York), not just the offset or short, ambiguous timezone code (EST).

There's no allowance in ISO 8601 for this, so you need a side channel like another field to communicate this. I've seen other date formats do something like 2021-10-11T12:13:14[America/New_York] to allow for this. Once you do this, it probably makes sense to elide the offset to avoid the risk of consfusing mismatches between it and the timezone.

As far as I know, there isn't an official standard for timezone names so you need to define which set of names you are using.

IANA tzdb is the defacto standard in the software industry.

In my view what's best is to always pass around utc but include the Z to make it explicit that's what you're doing. It's a very succinct way to represent that and can be very valuable to disambiguate so I think it's worth the extra character.

Sometimes you are defining a date by the local time.

I have a meeting on June 13th 2026 at 15:00 london time.

This could be 2026-06-13 14:00:00 Z

But if the U.K. drops summer time, or makes it double summer time, the meeting will still be 1500 london time, but the UTC time might change to 1500Z or 1300Z

One of the aims of RFC 3339 is to eliminate the ambiguous variants from ISO 8601, so it makes the timezone obligatory. Timestamps without a timezone are in an unspecified local time.

Timestamps with a timezone are in UTC.

It's only needed for disambiguation.

That said, I wish the page had actually taken the local time into account. As in your case the times on the page are in my current timezone (CEST) so the "Z", "00:00", "+00:00" is basically just decoration.

~~Even worse, in the intersection we have formats like %h:%m:%s+Z and %h:%m:%s+02:00 that show the same time simultaneously.~~

Edit: it is correct now.

I'm in the America/New_York zone and I see the proper times for the values with "Z" vs the values with "-4:00". That is, they are off by four hours.

I’m in America/New_York as well and I see them correctly. I think your computer’s time zone may be incorrect.

Reply on news.ycombinator.com