Chris Nandor <[EMAIL PROTECTED]> writes:
> Here are some comments from Matthias Neeracher, the MacPerl author, and
> a few comments from me.
Cool, thanks.
>> Is it? I thought DOS/Windows uses 1900, but I don't know what Perl on
>> these platforms does.
My understanding is that the native epoch of DOS was 1980, but I don't
know if Microsoft has since changed that from the Windows 3.1 days (which
were the last time I used a Microsoft operating system for more than a few
minutes needed to get to a terminal emulator and a Unix machine).
>>>> All versions of Perl on all platforms should maintain time both
>>>> internally and externally as seconds since the UNIX epoch (00:00:00
>>>> 01 Jan 1970 UTC).
>> Note that this assumes that all systems on which Perl runs know what
>> time zone they are in. This assumption may not universally hold.
This is a good point which is very much worth bearing in mind. It's not a
problem on Unix systems, since Unix time is in UTC (well, a slightly weird
UTC, but close enough for most purposes). This isn't the normal case on
Windows (and possibly Mac; I don't know), where normally the system clock
is kept in local time instead. This historically is due to Unix having
generally better time zone handling than the personal computers of the
time (back in the 1980s).
If you keep the system clock in UTC, you *have* to understand time zones
and get them right, up to and including daylight savings time, or the user
will be confused. If you keep the system clock in local time, you can get
away with knowing nothing about time zones and often with knowing nothing
about daylight savings time and relying on the user to reset the computer
clock like they would the clock on their microwave.
It may not be *possible* to convert the internal clock of some systems to
a Unix epoch; it may in fact not be possible to convert it to anything
consistent at all because the actual value of the epoch may be completely
unknown. I have no idea how to deal with that problem.
>> Personally, I find consistency between Perl internal calls and direct
>> system calls more important, but I know that this is a minority
>> position.
I'm rather sympathetic to this position personally, actually.
>> Also, at the very least, it should be stated that the value should have
>> at least 32 significant bits, i.e., be an unsigned 32 bit integer.
Unix time currently uses a signed integer for reasons related to error
handling on most platforms; unsigned time_t was tried as an experiment in
the 1980s in BSD and reverted because it caused too much confusion.
> Or, if we're gonna not go along with the standard time_t, might as well
> make it 64.
32 bits is clearly insufficient; I would support that.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
