# ISO 8601

Date/time separation, further component separation inside those, different radices of those, arbitrary units, calendars, leap seconds and days, time zones, and finally awkward time formats – all those are arbitrary to various extent (some are loosely based on observed cycles), and lead to unnecessary complexity and bugs in software, occasionally inspiring programmers to get creative and make it worse with new encodings.

ISO 8601 was supposed to at least alleviate the time format issues, but perceived user preferences tend to be preferred over it, so at best it gets used in systems internally.

A way to share approximate timestamps between programs, even if not a sane way to work with those, would still be useful, but what we have now is incompatible ISO 8601 implementations. For instance, the paywalled (and apparently copyrighted) text of the standard says that a dot <emph>or</emph> a comma can be used to separate the fractional part; of course some programs print and/or parse only dot, others – only comma, yet others – varying, depending on locale, for instance. Some would be rather liberal with time zone designators, while local time is allowed, and some won't parse what they've printed. Those are not amateur projects, and they tend to stay the same after bug reports – for the usual WONTFIX reasons such as backwards compatibility, not being important or an issue at all, possibly redirecting to related projects where the report dies.

And then there are profiles, particularly RFC 3339: it is supposed to resolve the ambiguities and generally be more useful for interoperability (and it succeeds at that), but it is quite restricteve, which may be a problem if you only need dates, or a higher precision.

The issue is not specific to this standard, since people do it with standards all the time, yet the ambiguity in the standard doesn't help, and neither does the paywall. Though it is still better than no standard at all: at least most of the time it is possible to guess what is wrong and find a workaround if it is known that given or accepted timestamps correspond to someone's idea of ISO 8601.

Yet another issue, also common among formats, is that it is not easy to parse without a proper parser. One should use a proper parser, but for most that is arcane art, for some it is unnecessary and/or undesired dependency, and it seems like most of the time parsing is done with regular expressions, `scanf(3)`, various string manipulation and conversion functions. I used to think that sticking to regular grammars may help to ensure correct implementations, but apparently it will not help much either, while a strict and as dumb as possible format probably would; there is inherent complexity of time components, of course, but ISO 8601 introduces alternatives that could have been avoided.

A nice way to deal with time would probably involve natural units (e.g., Planck time) and a better model (relativistic), probably logarithmic scale and base 2 or 3. But using something like that now would just introduce a new, particularly weird format, with complex conversion rules, with implementations dependent on common units anyway. Perhaps the closest commonly used thing to it is Unix time, but opting even for that would likely introduce unnecessary incompatibility issues, and/or require frequent conversions, since the used time components are embedded into cultures – which do not seem like they should affect technologies any deeply, but they do.

It would have helped if projects did not reimplement it on their own, but used some common library with proper RFC 3339 (or full ISO 8601) printing and parsing (and perhaps other time-related functions), but as usual, it is not something that is likely to happen: native implementations are usually preferred, sometimes even "native" to a program in question.

I keep writing and removing a rant like this every few years (sometimes ranting about other units of measurement as well), since it's not a useful note, but perhaps should finally leave it here. At least it's not likely to become outdated in the observable future.

Though perhaps being paywalled is an even more frustrating aspect of ISO standards in general: there are ISO(/IEC/IEEE) standards for all sorts of things, yet they are not usable in many cases because of the paywall, so you have to look for alternatives or write them from scratch, which seems to contradict the point of having standards.