Hacker News Reader

Comment by jstrong | Hacker News Reader

personally I think the mistake is trying to fit both purposes into a single format or type. as you state, it's a fundamentally different data type. representing a fixed moment in time is hard. representing a "floating" time of day is hard. trying to do both with the same type is pretty insane, but unfortunately common.

View on HN

It wouldn't really be much different if we had ISO8601.1 and ISO8601.2, would it? The standard can define two different types, and it makes it clear what it means to have a time without an offset specifier. It also defines formats for durations, intervals, and repeating intervals.

Is the distinction in representation too subtle?

We accept this subtlety elsewhere; we are used to 0 and "0" being different things, and expect them to behave differently under operators. Few would find the following surprising:

    0 + 0 == 0
    "0" + "0" == "00"

Then why would we expect these to behave the same?

   20200710T010000Z + `3 hours`
   20200710T010000 + `3 hours`

The first is a fixed timestamp in UTC, the result of the second depends on timezone.

Good point, which is why ISO 8601 does have a very different duration format (though the options for it such as calendar weeks make it a lot more obvious why it isn't just HH:MM:SS).

Maybe there should be a "float" offset marker. Another thing I was reminded of is that +0000 offset should be Z (UTC), but it is often application dependent if -0000 offset is also Z as some applications use -0000 for "user local time, regardless of user". Which is related to "floating", but yet another semantic difference.

I haven't run into that use of -0000, that's insane.

I suspect a side-effect of libraries lacking support for the full range of ISO8601 (for example, refusing to parse a value without an offset, forcing people to use such hacks). Wouldn't surprise me; iOS doesn't even have a consistent way to parse ISO8601 values with and without milliseconds.

[edit:

Apparently this is a RFC3339 thing, did not know that: https://tools.ietf.org/html/rfc3339#section-4.3

Negative zero offset is invalid in ISO8601, but valid and carries the meaning you describe in RFC3339. I misread what that meaning actually is from your comment - it is different to a "floating" or unqualified local time, it always represents a UTC time but with an unknown local time offset. ]

Reply on news.ycombinator.com