Re: OT: Re: Less is more

At 13:58 04/05/2004, Iljitsch van Beijnum 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,
>
>IMO, this is only a problem if EVERYTHING else is also human readable. As 
>soon as there is binary data of any kind, you need a tool that can handle 
>this for even the most superficial glances at the stuff and then the two 
>lines of code that convert the date to something that is human readable 
>isn't an issue at all.

One of my personal 'aims' with 'mail-ng' is for everything to be human 
readable unless necessary. So, header fields should be human readable, 
binary attachments don't need to be. I've spent a lot of time writing & 
debugging implementations of protocols such as SMTP, POP3, IMAP4, LDAP etc, 
and the text ones are many times easier to deal with than the binary ones. 
(OK, this may be down to the vaguaries of ASN.1, but that in itself may be 
encouraged by the binary-ness of it)

An epoch value in text would be preferable to an epoch value in binary, but 
*I* would prefer something like the ISO format instead, but it wouldn't be 
that big a deal for me (the only real time it would be more useful is 
during debugging etc or problem diagnosis. It'd save time there.
(For instance, imagine having a raw protocol log, now imagine asking a user 
(via telephone) to look at a date header field - eg to see why a message 
has been delayed - it'd be easier to explain to them how to interpret the 
ISO format instead of an epoch value)

>>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).
>
>Yes, this is a problem.

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.. (And, once 
it's validated, it's trivial-ish to convert to a human readable date)

>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. This should work well both when 
>the local clock isn't all that good and is synchronized with UTC once in a 
>while, and when there is very accurate UTC support.

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. By the next day the leap second will have 'disappeared' rather 
than be accumulated as it would with a 'seconds since 20 years ago' type epoch.

But, would it make converting to a human readable date more complex? 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?

>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? Would any OS know about leap seconds 
enough to be able to report it in a 'get time' API? If you 'forbid' sending 
mail at x:yy:60 times, then all an implementation which IS aware of leap 
seconds needs to do is to either advance or retreat a second when 
generating the time stamp. The majority of implementations which are 
blissfully unaware of leap seconds will just carry on as normal.

>>(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.

Paul				VPOP3 - Internet Email Server/Gateway
[email protected]			http://www.pscs.co.uk/