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.
