Tim Jenness <[EMAIL PROTECTED]> writes:
> Of course, "seconds since 1970" is only obvious to unix systems
> programmers.
I disagree; I don't think that's been true for a while. It's certainly
familiar, if not obvious, to *any* Unix programmer (not just systems
programmers), as it's what time() returns, and pretty much any C
programmer will have used that at some point or another. It's also so
widespread as to be at least somewhat familiar to non-Unix programmers.
Anyway, it doesn't matter; it's a lot more widely used than any other
epoch, and epochs are completely arbitrary anyway. What's wrong with it?
> MJD is doable with current perl 32bit doubles. I use it all the time in
> perl programs and am not suffering from a lack of precision.
Day resolution is insufficient for most purposes in all the Perl scripts
I've worked on. I practically never need sub-second precision; I almost
always need precision better than one day.
If we're aiming at replacing time, it has to provide *at least* second
precision, at which point I really don't see the advantage of MJD over
Unix time. Why change something that works?
Is Perl currently using different epochs on different platforms? If so, I
can definitely see the wisdom in doing something about *that* and
off-loading the system-local time processing into modules (although I can
also see the wisdom in leaving well enough alone). But why not go with
the most commonly used and most widely analyzed epoch?
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
