[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
support@xxxxxxxxxx			http://www.pscs.co.uk/