3 ms·

One part of RFC 3339 I dislike is `Z` vs `+00:00` vs `-00:00` > Unknown Local Offset Convention > If the time in UTC is known, but the offset to local time is

One part of RFC 3339 I dislike is `Z` vs `+00:00` vs `-00:00` > Unknown Local Offset Convention > If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". > This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time. `Z` should have been used to represent the unknown local time case, and `-00:00` shouldn't exist, while `+00:00` could be used if UTC is the preferred reference point. In practice `Z` is already used for the "no preferred local time" case very often.

burkaman 3y ago
Wow that is very surprising, I always thought -00:00 was just a synonym for +00:00. That seems almost intentionally misleading, why not Z like you say or just +? or something?
- deleted 3y ago
  [deleted]
- foresto 3y ago
  Reminds me of the +1 / -1 / +0 / -0 convention that was once common in open source development discussions. For example: https://community.apache.org/committers/consensusBuilding.html#expressing-support-or-otherwise https://community.apache.org/committers/consensusBuilding.ht... I wonder if that convention had something to do with this choice of syntax.
mankyd 3y ago
Thank you for this comment. I saw the `-00:00` in the RFC 3339 bubble, and was confused as to why it wasn't mutually agreed upon. Your comment makes clear the the `-` has special meaning that I hadn't picked up on.
toast0 3y ago
I thought Z was a reference to (NATO) Military time zones [1], where Zulu Time Zone is equivalent to UTC+00:00, but uses fewer characters. iCal uses the Z to indicate times intentionally in UTC as well, as opposed to times without a time zone indicator (use unknown local time), or times with an explicity time zone indicator. Using Z to indicate 'please use whatever local time seems appropriate' seems like poor practice, even if it's a common one. [1] https://en.wikipedia.org/wiki/Military_time_zone https://en.wikipedia.org/wiki/Military_time_zone
- wlonkly 3y ago
  I thought the same (Zulu), and the RFC 3339 definition for "Z" mentions "Zulu" as well. Nautical time has also used Z/Zulu for 0-offset since before World War II.
- CodesInChaos 3y ago
  In my experience "this timestamp is UTC, show it to the user in whatever timezone they might be in" is the most common case for times in an API/file format, so giving it the Z shorthand makes sense to me. While when using an explicit time offset, `+00:00` doesn't appear particularly special or more common than other offsets, so I don't think a shorthand for this case is useful.
  - dwaite 3y ago
    Other than instants in time and durations, other expressions of time information tend to be a bit more "wibbly wobbly, timey wimey". For instance, I might specify the week of the year without any more precision. Another example is that a date can't be converted to a range of instants in times (the first and last second within the day) without knowledge of where it is observed. Games for instance will measure this at some business-decided timezone (say UTC or the timezone of their first server), because having events time out at different times for different people is much more complex. So when representing an instant in time, a UTC shortcut is easier - if people agree that times are shared with a Z offset, then you simplify parsing. However. there are reasons people would also want a fully specified point in time that preserves a timezone offset as well.
taftster 3y ago
Fixed this for you: In practice `Z` is already used *wrongly* for the "no preferred local time"
zerocrates 3y ago
I assume they chose -00:00 because ISO 8601 forbids it, so there isn't an issue of a compliant ISO 8601 stamp having a different meaning under the RFC. Does anything in practice care about + vs. - 00:00, though? Seems kind of unlikely to be widespread. Among other reasons because people don't know about it. I think if anything I'd have just left the concept out entirely.

burkaman 3y ago

Wow that is very surprising, I always thought -00:00 was just a synonym for +00:00. That seems almost intentionally misleading, why not Z like you say or just +? or something?

deleted 3y ago
[deleted]
foresto 3y ago
Reminds me of the +1 / -1 / +0 / -0 convention that was once common in open source development discussions. For example: https://community.apache.org/committers/consensusBuilding.html#expressing-support-or-otherwise https://community.apache.org/committers/consensusBuilding.ht... I wonder if that convention had something to do with this choice of syntax.

mankyd 3y ago

Thank you for this comment. I saw the `-00:00` in the RFC 3339 bubble, and was confused as to why it wasn't mutually agreed upon. Your comment makes clear the the `-` has special meaning that I hadn't picked up on.

toast0 3y ago

I thought Z was a reference to (NATO) Military time zones [1], where Zulu Time Zone is equivalent to UTC+00:00, but uses fewer characters. iCal uses the Z to indicate times intentionally in UTC as well, as opposed to times without a time zone indicator (use unknown local time), or times with an explicity time zone indicator. Using Z to indicate 'please use whatever local time seems appropriate' seems like poor practice, even if it's a common one. [1] https://en.wikipedia.org/wiki/Military_time_zone https://en.wikipedia.org/wiki/Military_time_zone

wlonkly 3y ago
I thought the same (Zulu), and the RFC 3339 definition for "Z" mentions "Zulu" as well. Nautical time has also used Z/Zulu for 0-offset since before World War II.
CodesInChaos 3y ago
In my experience "this timestamp is UTC, show it to the user in whatever timezone they might be in" is the most common case for times in an API/file format, so giving it the Z shorthand makes sense to me. While when using an explicit time offset, `+00:00` doesn't appear particularly special or more common than other offsets, so I don't think a shorthand for this case is useful.
- dwaite 3y ago
  Other than instants in time and durations, other expressions of time information tend to be a bit more "wibbly wobbly, timey wimey". For instance, I might specify the week of the year without any more precision. Another example is that a date can't be converted to a range of instants in times (the first and last second within the day) without knowledge of where it is observed. Games for instance will measure this at some business-decided timezone (say UTC or the timezone of their first server), because having events time out at different times for different people is much more complex. So when representing an instant in time, a UTC shortcut is easier - if people agree that times are shared with a Z offset, then you simplify parsing. However. there are reasons people would also want a fully specified point in time that preserves a timezone offset as well.

taftster 3y ago

Fixed this for you: In practice `Z` is already used *wrongly* for the "no preferred local time"

zerocrates 3y ago

I assume they chose -00:00 because ISO 8601 forbids it, so there isn't an issue of a compliant ISO 8601 stamp having a different meaning under the RFC. Does anything in practice care about + vs. - 00:00, though? Seems kind of unlikely to be widespread. Among other reasons because people don't know about it. I think if anything I'd have just left the concept out entirely.