Chaim Frenkel <[EMAIL PROTECTED]> writes:
>>>>> "AD" == Andy Dougherty <[EMAIL PROTECTED]> writes:
>AD> In my humble opinion, I think perl's time() ought to just call the C
>AD> library's time() function and not waste time mucking with the return
>AD> value. Instead, if the time is to be stored externally for later use by
>AD> another program, the programmer should be responsible for converting the
>AD> time into a suitably useful and portable format. Any unilateral choice
>AD> made by Perl6 in that regard isn't going to be of any help unless everyone
>AD> else (Java, Python, C, etc.) follows along.
>From the perspective of a non-Unix user that has been fighting this battle
for a few years now, you can't just take the C library time() on all systems.
And yes, the programmer does need to take responsibility for external formats,
regardless of the internal time representation used, and regardless of what
"everyone else is doing".
On at least some non-Unix systems, the time() function is itself an attempt
to emulate Posix functionality...note that I say "attempt". And also note
that Posix != Unix. One can have library functions in perfect compliance
with published Posix standards, but when Unix programmers see the result
they say "that's evil".
An example: gmtime() on my system returns 0. Why? Because the system
runs on "local time" and has no idea of the offset to UT.
It's a perfectly Posix-compliant result, but causes no end of problems
with programs written for Unix. Ditto for the epoch of 1 Jan 1970 0h
in local time rather than UT.
-> programmers make assumptions based on what they're used to
>Possibly a few functions to make it easy.
>
>$Perl::EpochOffset
>
> 0 on a unix box
> 966770660 on a Mac (Lifted from pudge's previous email)
> etc.
>
I don't know how many places there's an implicit "Epoch=0" embedded
deeply in Perl modules and apps, but I've run into plenty of them.
Adding a module to define epochs will sure help, but as long as the
"default" is so simple, plenty of programmers will just assume Epoch=0
and build it into their code.
So my suggestion is that either Epoch=0 for everyone, or make it
distinctly non-zero for everyone so lazy programmers have to use
$Perl::EpochOffset everywhere.
>One other that might be useful is have strftime() (or something
>similar) built-in without having to use POSIX; and the default should
>be YYYYMMDDHHMMSS.fffffff, (the ISO format)
Sounds really good to me.
>I personally prefer to pass around the string representation, more
>that perl and unix systems need to handle datetime. (And I find it
>easier to read the ISO version than a time in seconds)
Agreed, and having built in functions that can convert to/from ISO
format to internal representation would be a great help.
Just to stir things up a bit: if you want to consider abandoning the
"unix standard time()" to get higher resolution, etc., take a closer
look at the VMS native time, modified to be UT rather than local
time.
It has 64 bits for a huge range, with "ticks" of 100ns. The epoch is
17-Nov-1858 so no problems with pre-1970 dates in databases...and I
*believe* that epoch date comes from the "modified Julian Day" epoch
(MJD = JD - 2,400,000) so there's a very simple conversion to Julian Day.
--
Drexel University \V --Chuck Lane
======]---------->--------*------------<-------[===========
(215) 895-1545 _/ \ Particle Physics
FAX: (215) 895-5934 /\ /~~~~~~~~~~~ [EMAIL PROTECTED]
