On 14 Aug 2000, Russ Allbery wrote:
> Nathan Wiger <[EMAIL PROTECTED]> writes:
>
> > The idea would be twofold:
>
> > 1. time() would still return UNIX epoch time. However, it
> > would not be in core, and would not be the primary
> > timekeeping method. It would be in Time::Local for
> > compatibility (along with localtime and gmtime).
>
> > 2. mjdate() would return MJD. It _would_ be in core, and
> > it _would_ be the internal timekeeping method. All
> > of the new date functions would be designed to be based
> > off of it.
<snip>
>
> By comparison, who uses MJD? Practically no one. It's a theoretically
> nice time scale, but outside of the astronomy community, how many people
> even have any idea what it is?
>
In one of my previous posts I was simply suggesting that the Date object
(whatever it is) should have a method to return the internal format
(seconds, mjd, whatever) to allow for simple date arithmetic without
having to do anything more complicated. unix seconds and mjd both will
allow this.
> This appears to be a proposal to replace a *very* well-known time base
> with very well-known and commonly-used properties with a time base that
> practically no one knows or currently uses just because some of its epoch
> properties make slightly more sense. Unless I'm missing something
> fumdamental here, this strikes me as a horrible idea.
Of course, "seconds since 1970" is only obvious to unix systems
programmers. "Number of days since XXX" is just as valid for someone
coming to the language from a different direction and at least has some
kind of basis outside of computing.
>
> Unix's time representation format has no fundamental problems that aren't
> simple implementation issues. Negative values represent times before 1970
> just fine. The range problem is easily solved by making it a 64-bit
> value, something that apparently we'd need to do with an MJD-based time
> anyway. And everyone already knows how it works and often relies on the
> base being consistent with their other applications.
>
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.
In fact RFC #7 ("Higher Resolution time values") suggests that the
concept of "number of seconds since epoch" will have to make room for
fractions of a second anyway.
--
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj
