This is getting off-topic for a persistence list, but for lack of a
better forum...

> timestamps present at least the following concerns:
>
> - Precision
> - Accuracy
> - Different epochs
> - Different time zones
> - Leap seconds (UTC vs TAI)
> - YYYY-MM-DD dates vs seconds-since-Epoch timestamps
>
> getting people to actually follow it instead
> of merely pretending to follow it is ten times harder

There's a similar problem with strings. You can specify that "strings
are UTF-8" but you just know people are going to stuff broken UTF-8 and
random charsets into it :)

It seems the only solution that might work is to have a separate "I know
what I'm doing" mode that is off by default.

So the default string encoding is "assume it's UTF-8 but don't be
surprised if that fails to decode or looks weird". There would be a
separate mode for "no, really, I promise that it's charset X" where
UTF-8 is one possible value of X.

With timestamps, people are probably going to notice it they are off by
an hour or more. So we can mostly trust people to get the date, time and
timezone right (so long as timezone information is always preserved or
the timestamp is UTC; people have wised up enough since the nineties
that this is mostly the case now). But I'd put any promises about
UTC-vs-TAI behind a separate "I know what I'm doing" flag. The default
simply would not say whether it is UTC or TAI! What's more, even people
who know about UTC vs TAI do not necessarily have an up-to-date leap
second table, so the time may still be off.

string -- name of the encoding, plus contents of the string. The
encoding name is usually blank. That means: "Assume UTF-8 if you don't
know better, but don't be surprised if you get weird arbitrary bytes."
If the encoding is explicitly filled in, the writer claims that they
know that's the real encoding.

time -- Positive or negative seconds since epoch, and a timezone. The
epoch is always 1970; the seconds are always GMT/UTC/TAI; you can apply
the timezone to the given seconds manually if you want to, or opt to
keep them as GMT/UTC/TAI. There's a separate leap-second adjustment
flag: UTC, TAI, or "don't know". The default is "don't know". If it's
UTC, the writer claims they know the timestamp comes from a source that
tracks UTC. If it's TAI, the writer claims that it comes from a source
with an up-to-date leap-second table that tracks TAI.