- ISO 8601 is paywalled
- RFC allows a space instead of a T (e.g. 2020-12-09 16:09:…) which is nicer to read.
Z indicates UTC. Alternatively,
2023-12.12T21:18-05 for time zone as central. The UTC time zone code at the end just tells you where the time is taken from. Usually Z is used since, well, it’s “universal,” but having a +13 or -06 or whatever else brings context, and allows computers to synchronize the string of text into a comparable time for event logs and such.
Yes. The RFC is missing something that explicitly indicates the time zone. The Z is a great unambiguous way of saying “yes, this is UTC.”
IMO, ISO 8601 is better for computers, people working with multiple time zones, or critical logging.
RFC 3339 is better used colloquially, while still remaining unambiguous for the use cases that most people use dates and times in.
I’d rather have an explicit time zone any time a datetime is being passed around code as a string. Communicating it to a human is relatively safe since even if there’s a mistake, it’s directly visible. Before that last step, incorrect time zone parsing or implicit time zone assumptions in code that was written by “who knows” in the year “who knows” can be really annoying.
There’s a new RFC in the pipeline that will address this.
It’s already been approved, just needs to slooowly crawl its way theough the final publication queue.
Thanks for the link. Reading it gave me a headache. Not because of the proposal, but because of the very clear explanation it includes of just how annoying time zones are. I never even thought about the fact that a time relative to a UTC timestamp isn’t uniquely associated with another UTC timestamp because the local UTC offset can change. It’s obvious when you say it, but now I’m wondering if I have more time zone bugs somewhere.
