Re: OT: Re: Less is more

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.