Can one detect the date and time format in an ISO8601 string?

Question

It's trivial to find libraries which say they can parse a time or date and time presented in ISO8601. What they all seem to mean is that they can be configured to parse one format of ISO8601, for instance by hand-rolling a suitable string format code.

But in fact ISO8601 defines a wide variety of possible formats for representing date and time. For instance, to give a very short list of variations:

• various separators are optional or allowed to be different characters (e.g., you can use a space or "T" between the date and time part, and you can omit hyphens between date components)
• you can represent moments with varying degrees of precision, so that "2018" is a valid ISO8601 string I believe
• you can specify time via day-of-the-month, or day-of-the-year, or week numbers
• you can specify time zone offsets in various ways (e.g, "+01:00", "+0100", or "+01")
• etc..

You could almost say, ISO8601 defines an entire DSL for representing dates and times. If you only know a string is an ISO8601-formatted time, you don't know much.

So what I'm wondering is this: Can you read a string, knowing only that it is encoded in some ISO8601 format, and reliably infer which format it is using? Or are the ISO8601 formats unfortunately defined in such a way that a parser needs to know ahead of time which format is being used?

Answer 1

It's an interesting question, but the answer is invariably no. To parse a string is not only to evaluate its characters, but to evaluate them with specific intent.

In other words, what would you parse it into? If one has a string that might contain a date, and might contain a time, and might contain an offset from UTC, or might contain a week-of-the-year based value, or might contain a period of elapsed time, and might contain a range of such periods, possibly with a fixed point at one end... Such a resulting object that could parse all of them would not be very useful. One would have to test a lot of optional properties of that object in order to know how to use it. Perhaps one might use such an object for validation of the string being in one of a handful of valid formats, but regular expressions are much better suited for that task.

It's worth mentioning that languages that have tried to make one-date-time-type-to-rule-them-all usually have ended up regretting it. Consider java.util.Date which fell into this trap. Java developers should know by now that they should be using java.time or Joda-Time instead. Also consider schema languages like XSD, which have a wide variety of date and time types defined, many of which are ISO8601 compatible. If there was only one type, it would devalue the purpose of defining a schema.