On Wed, 5 May 2004 00:24, Paul Smith wrote:
Well, it's trivial to generate the ISO format. Validating it may be harder
(but certainly not harder than the RFC822 form AFAICS), but, how often does
it need to be validated and not converted to human-readable..
That depends on how strict you want the overall protocol to be. If the only
time a date field is used is when it's displayed to the user, then it's
possible for all intervening MTAs to ignore that data. That being so, the
intervening MTAs will, technically, be forwarding malformed data (and
propagating a protocol violation) when the incoming data is malformed. If the
MTAs parse it (just to check syntactic validity), then the error can be
detected at the outset. It's debatable as to which of these scenarios is
preferable.
But maybe there is some middle ground to be found by keeping the date and
the time apart. So use epoch style for both independently: a day number,
and a number of seconds since midnight.
That's an interesting idea.. Leap seconds wouldn't be a real issue then.
It'd just mean you'd have to allow 0-86400 as valid second values instead
of 0-86399.
You'd still run into difficulty with date calculus, particularly relating to
timezones. If you compute your timezone shifts using arithmetic modulo 86400,
you're effectively pretending to work in UT1 rather than UTC. Whenever you
perform an addition or subtraction which crosses a quarter-year boundary, you
need to know whether you crossed a leap second or not.
If you're going to insist on UTC, you ought to do a proper job of implementing
it, right? If you insist on UTC, you get all the implementation quirks that
leap seconds imply. The only way to dodge leap-second headaches is to not
have them. This means using UT1, or the subset of time calculus which is
common between UT1 and UTC (which is everything up to, but exclusive of, the
seconds).
Are there any commonly available functions which could take a day number
to produce a y/m/d format? Would these functions be simpler than one to
validate an ISO date?
The ISO C specification of mktime() can be used for both these tasks, since it
allows "denormalised" dates: when invoked on a struct tm, the function
performs normalisation on that structure.
For conversion from epoch offset (if your offset is in days), express the
epoch as a struct tm and add the offset to the tm_mday element. If the offset
has a fractional component, multiply the fraction by 86400 and add the
resulting value to the tm_sec element. The method has accuracy to plus or
minus a second, or the resolution of the fractional part used, whichever is
coarser.
Validation of an existing date can also be done with this function: parse the
date into struct tm format (relatively trivial for ISO dates), duplicate the
structure, pass one instance to mktime(), and if mktime() does not report an
error, compare the two for differences.
mktime() also converts to time_t epoch offset, but it treats the converted
date as a date in the local timezone, so this is only likely to be useful if
that relation holds true. You could convert the date into your local timezone
by an appropriate addition or subtraction from the tm_hour field, but this is
starting to get a little messy.
Reference: http://www.opengroup.org/onlinepubs/009695399/functions/mktime.html
We can even make a rule that forbids sending mail at leap second times to
keep implementations simple. :-)
Why not? Sounds eminently sensible to me. Realistically, would anyone care
about leap seconds when sending email?
If you're going to insist on "no leap second dates", you may as well do a
conversion from UTC to UT1 at the outset (converting any instance of 60
seconds back down to 59), since this gives you 0.9 second accuracy anyhow.
Why the on-going enthusiasm for half-baked UTC implementations, folks? Do it
right or do something else, I say.
If nobody cares for leap seconds, then perhaps nobody cares for seconds at all
in this instance. That being so, we can declare the time structure without
seconds, suggesting that it should be accurate to plus or minus a minute.
This renders the UTC versus UT1 debate irrelevant: they both meet these
criteria.
(Assume you have a convenient
list of leap second instances available in both cases.)
I think this is exactly the one thing we can't reasonably require.
Exactly.
Any time function library that wishes to deal in UTC calculus absolutely
requires such a list. You can't do accurate UTC computations unless you know
where the leap seconds are. Leap seconds are generated on demand when the
Earth's rotational variance requires it (unlike leap days, which are
generated according to a formula). Without such a list, your options are UT1
and TAI, neither of which have leap seconds or other undetermined components.