Front page | perl.perl6.language.datetime |
Postings from August 2000
Chris Nandor <pudge@pobox.com> 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 (rra@stanford.edu) <http://www.eyrie.org/~eagle/>Thread Previous | Thread Next