First things first: more complicated ideas like “time of day” or “day of week” definitely don’t belong in JSON. The simplest reason is that no date-related API I have ever encountered treats these as anything more complicated than an integer, which JSON already has. Part of the beauty of JSON is that the types it contains map very nicely onto all sorts of type systems and standard libraries that have evolved organically over time. No matter what language I’m using, if I want to call a function that takes or returns “time of day” or “day of week” value, it is almost invariably passed/returned as an integer. So there’s no sense in adding something like this to JSON, any more than adding a way to annotate a string to say “this is a person’s last name.”

As far as calendars, time zones, leap seconds, and the like, I think a nice way to reconcile it all would be to introduce two different types: timestamp and date.

A timestamp would define a point in time, and be represented by unix epoch seconds. Advantages: pretty much everyone uses it already, it can be extended arbitrarily both forwards and backwards by throwing more bits at the problem, can represent arbitrary precision using real numbers, programs have easy access to it through their existing standard libraries, and almost every date library ever invented can manipulate it natively. Sure, it doesn’t work for people who have super-specialized needs, but those people KNOW that time_t does’t work for them.

A timestamp would say nothing about calendar day, time zone, time of day, or anything like that. It would be just a timestamp.

The other type could be a calendar day. Year, month, day, that’s it. Although this is slightly ambiguous (since it doesn’t specify the calendar), again I think we’re talking about a situation where assuming it’s gregorian will work for the vast, vast majority of applications. And again, people for whom this doesn’t work will definitely know who they are.

With these two types, I think you’d have a generally useful solution that covers the vast majority of programmers’ needs, and that don’t catch anyone off guard.

“@2007-06-28@” may work for some limited cases, but to use it as a general format is asking for trouble (in the same way sending character data without a defined encoding is asking for trouble). There are standard, unambiguous representations of dates, but they might not be as human-writeable as desired.

Also, different applications need different semantics from their date/time objects. Some don’t care about time zones; others do. Some need “time of day” or “day of week” objects. For many, date/time data is useless without being able to encode relative times and dates. I’m not sure any single interchange format can be useful in the real world while still remaining simple to write and parse. (At least with character encoding, basically everyone can agree on UTF-8.)

I don’t think I understand what *you* mean by “self-describing.”

But what do you mean by “self describing”? To me JSON is the canonical non-self describing language – all its structure is inferred in the spec and none of it comes from the data you’re getting.