Question

Is there a reason why the NodaTime JSON.net serializer does not use the ISO8601 Time Interval format to express the start and end instants?

Example ISO8601 Time Interval:

"2007-03-01T13:00:00Z/2008-05-11T15:30:00Z"

NodaTime Complex JSON:

{ Start: "2007-03-01T13:00:00Z", End: "2008-05-11T15:30:00Z" }

Is the ISO8601 format just not a good fit for the interval concept in NodaTime?

Was it helpful?

Solution

Is there a reason why the NodaTime JSON.net serializer does not use the ISO8601 Time Interval format to express the start and end instants?

Yes. I didn't spot it when reading ISO-8601. It's not a very good reason, but it's the correct one.

Is the ISO8601 format just not a good fit for the interval concept in NodaTime?

Nope, it's a perfectly good fit (as good as the rest of ISO-8601 is), and we should absolutely have used it. I don't think ISO-8601 specifies that the start is inclusive and the end is exclusive, but that doesn't need to be an issue.

I suspect the format we'd want to use would be the extended ISO format to include sub-second values, in line with everything else, but I suspect that sort of extension is fairly common.

We'll need to make this an option when configuring the JSON serializer, which is a slight nuisance, but we should definitely make it available.

I've opened feature request 270 to cover this.

OTHER TIPS

I'm going to respond to this slightly differently than Jon did. I welcome any counterarguments.

Is there a reason why the NodaTime JSON.net serializer does not use the ISO8601 Time Interval format to express the start and end instants?

Yes. By keeping the start and end points of the interval as separate values, they are individually addressable by any JSON parser. Since each instant of the interval is expressed in UTC (with the "Z" ending), then they are individually sortable as well.

This makes it quite easy to perform range queries in JSON-based databases, such as in RavenDB. (See also RavenDB-NodaTime)

It also allows to quickly compute validity (start <= end) and duration (end-start) without having to break out of JSON and split the string.

The ISO interval format could work here, but it would not be as convenient from a JSON perspective.

Is the ISO8601 format just not a good fit for the interval concept in NodaTime?

It's a great fit for Noda Time. It's just not a great fit for JSON. I would expect that Interval.ToString() and related text patterns for Noda Time would use the ISO format. If they don't, then there's something to work on for a future release.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top