There is already precedent (-M, et alia) for a "perl epoch" which is time
since the start of execution of the script. Negative numbers are used to
represent times prior to the start of execution, and positive numbers are used
to represent times after the start of execution.
The "perl epoch" doesn't suffer from Y2K syndrome :) (irrelevant comment)
In perl 5, the perl epoch is definitely based on days since the time() $^T the
script started.
Really, once you define a mechanism for storing a sufficiently large time of
adequate span and resolution (64 bits?), the remaining problem is just a
matter of selecting a base time (what does 0 mean?), and the units (what does
1 mean?). Given a base time and the units...
...conversions between MJD and the perl epoch, between UTC and the perl epoch,
and between common current time in any time zone and the perl epoch, should
just be a single subtract each, so a few constants (and a time zone offset
setting) in a module should be able to give anyone interested in any of those
the actual time.
...conversions between at least one of the above, and Gregorian dates should
be available.
...the time objects provided by perl should allow users to:
: obtain nicely formatted times in any of the above systems
: supply a timezone offset, and obtain nicely formatted dates in any
timezone
: obtain any/all of the numeric component parts of any of the above times.
Such will take quite a few methods on a class, or a function returning a large
number of components or keys & values.
For consistency, it would be nice if all the perl APIs used the same epoch
when dealing in binary timestamp values.... and that conversions from host
operating system API formats would happen automatically.
Russ correctly points out that Unix's time representation format has no
fundamental problems that can't be solved by simple workarounds. Neither does
MJD or UTC. There is no universal epoch among platforms or operating
systems. Picking Unix time would make one user community happy, picking
Windows time would make a different user community happy, picking MJD would
make a different user community happy, there is no epoch that would make
everyone happy, so I propose the perl epoch be based on the time the script
starts running, similar to -M, but perhaps with a different unit than days
(which implies floating point) if we want a 64 bit integer representation.
Keeping the base consistent with other applications is only relevant if
reading and writing binary form timestamps created by the other
applications.... conversion to/from the binary form used by those other
applications should be encapsulated on two functions that read/write the
binary data from those other applications. For a Unix user that is likely to
require a different conversion that a Windows user. Converting to/from Unix
binary timestamps and Windows binary timestamps would be nice convenience
functions to have built in to perl. I would even find the conversion to/from
Unix timestamps handy on Windows, and vice versa, for data that is networked.
Russ Allbery wrote:
> 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.
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_____NetZero Free Internet Access and Email______
http://www.netzero.net/download/index.html
