On Tue, 4 May 2004 18:31, Paul Smith wrote:
Going for an 'epoch' system (eg seconds since 17th March 1973 or whatever)
is (IMHO) more problematic since you start getting affected by leap-seconds
(or at least having to worry about how not to be affected by them) - it's
also less human readable.
I won't argue with your "less human readable" assessment, but I will point out
that it is correspondingly more machine readable. The grammar for a valid ISO
date of the form you specified may seem trivial, but it isn't once you check
for all conditions (appropriate month lengths and leap year rules). Epoch
offset *is* trivial, because every valid number corresponds to a unique valid
date.
But don't think that the ISO format is simpler with regards to leap seconds!
The only simple way to deal with leap seconds is not to use them. Suppose
it's a leap second day at the end of June, and the time is 23:59:60 UTC. If
I'm in the +1000 zone (ten hours ahead), what time is it locally? What time
is it in the -0500 zone? Is it easier to compute this result from a
partitioned date (like ISO) or an epoch offset? (Assume you have a convenient
list of leap second instances available in both cases.)