Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch
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 MMDDHHMMSS.fff, (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]
Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch
Andy Dougherty [EMAIL PROTECTED] writes:
On Thu, 14 Sep 2000, Charles Lane wrote:
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
Do you mean that the following program might not print '5' (well, about 5,
given sleep's uncertaintites ...)
#include stdio.h
#include sys/types.h
#include time.h /* May need sys/time.h instead */
int main(void)
{
time_t start, stop;
start = time((time_t *) 0);
sleep(5);
stop = time((time_t *) 0);
return printf("The difference is %ld seconds.\n", stop - start);
}
If you mean the above program won't print '5', then I don't see how
changing the epoch could possibly help. More radical surgery is required.
Run that program during a DST change on my system, and you'll get +-3600
instead of 5. Yes, more radical surgery IS required, and you can't just
take the C libraries "time()" function and expect it to be suitable for
Perl's time(). There's code to deal with this in Perl5's vms/vms.c.
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.
This is not a simple either-or.
Of course not, it was stating a preference for either of two (out of
many) possible alternatives. Of those two, I prefer Epoch=0.
If Perl5 on VMS just used the time() function from the C library we'd
have Epoch=14400 part of the year and Epoch=18000 the rest of the year.
Varying from year to year. Think this is a good way to do it? I don't.
Suppose you are using a Mac and that
perl6 decides to use the Unix epoch. Suppose you want to communicate with
other Mac programs or library functions about time (e.g. perhaps by
calling things through the XS interface or by storing to a file). Since
the perl6 time() and C time() will now disagree about what time it is,
even the non-lazy programmer will have to use $Perl::EpochOffset
everywhere.
Whenever you communicate outside of Perl and you use "low level" data
you have to deal with the possibility of mismatches in things like
formats and representations (number endianness, floating point binary
representations, and yes, times).
When you're writing code to port to other applications you *should*
be looking out for stuff like this.
The problems that I ran into with Epoch != 0 were purely internal
to Perl...NOT the place where you'd expect to have to mess around with
EpochOffsets. That's programmers get sloppy.
In sum, *either* approach works in some situations and fails in others.
There is no universal solution. Epoch=0 everywhere will *not* solve all
problems. Nor will Epoch=native. Neither is perfect. Each has problems.
Agreed.
So we have to pick a default. (Yes, I'm sure everyone agrees that making
it easy to make the other choice via some nice module is nice too.) But we
have to pick a default. And I vote for perl's time() simply calling the
system time().
Andy, those of us using Perl on VMS for some years have had both defaults.
So there is some experience with this.
I've been in the Epoch !=0 mode and it sucked. I vote for Epoch=0 as
the default.
--
Drexel University \V--Chuck Lane
==]--*---[===
(215) 895-1545 _/ \ Particle Physics
FAX: (215) 895-5934 /\ /~~~[EMAIL PROTECTED]
Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch
At 11:01 -0400 2000.09.14, Andy Dougherty wrote: On Thu, 14 Sep 2000, Chris Nandor wrote: There's also the possibility of time accepting an argument, where 0 would be perl's time and 1 would be native time, or something. Now that's a clever idea. Hmm. I think I like it as a solution to the specific issue at hand better than the proposed time()/systime() pair. I think I'll "borrow" your suggestion for a longer posting on perl6-language :-). Be my guest. I am not favoring one solution or another, just throwing out ideas. I had tossed around the idea of drawing up several competing RFCs. :-) BTW, Nat noted that a moratorium on RFCs is FAST approaching, that Larry will make his draft feature set on Oct. 1, and his final on Oct. 14, so get any new RFCs in now. See http://use.perl.org/ for links to what Nat said. On the other hand, I'm not sure I like it too much as a general solution to the broader portable vs. native issue, since other functions with arguments can't be handled so cleanly. True. Yes, I know it's very very unfair to take your time() suggestion and try to apply it to a question like "Should unlink() on VMS unlink all previous versions (i.e. like a command line PURGE) or should it behave more like DEL and only delete the latest version? But the unlink() question is also a valid one with many of the same underlying issues. I'm currently trying to think about how to encourage us collectively to handle similar issues in similar ways. Well, I don't think it is entirely unfair. Also, what values do -T and stat() return? Well, -T is not so much of a problem as long as the epoch is still in seconds, but stat() sure is a problem. We could make stat take an optional second parameter. I don't think any other builtin would have the problem, but what about modules like Time::Local? -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch
At 11:15 -0400 2000.09.14, Charles Lane wrote: I've been in the Epoch !=0 mode and it sucked. I vote for Epoch=0 as the default. Well, Perl is about making things easy. What is the most common case, needing an arbitrary value of time that may or may not be used to transfer between platforms, or needing a value of time that is specific to a given platform? As noted, I can rarely rely on the Mac value anyway, since it changes with time zone. And I cannot think of a time when I have needed the actual Mac value to communicate with another Mac process or library. If the Perl epoch were used for MacPerl, I don't think I would _ever_ need to get the Mac OS epoch (though I would certainly want it available if necessary). I can't say the same for VMS, or for other Mac users. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch
On Thu, 14 Sep 2000, Chris Nandor wrote: Well, Perl is about making things easy. What is the most common case, needing an arbitrary value of time that may or may not be used to transfer between platforms, or needing a value of time that is specific to a given platform? And I cannot think of a time when I have needed the actual Mac value to communicate with another Mac process or library. Well, my entire experimental temperature control system currently relies on just this communication. But I suspect my personal experience here is probably not the most common :-). -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch
"CN" == Chris Nandor [EMAIL PROTECTED] writes: CN No, that won't really work. When my offset from GMT changes for daylight CN savings time, it will break. The point of having a module is that epoch CN conversions are more complicated than that. For example, Mac OS epoch CN begins at Jan 1 1904 00:00:00 _local time_. That is why the timezone CN offset from GMT was passed to the Time::Epoch functions. I'm confused. How do you expect the program to know the timezone if the OS doesn't? And if the program knows it and can track it, then we can hand off the responsibility to Perl. Then the epoch would 'vary' according to whatever nonsense is necessary. But if the values wander so badly, what does the OS use? If perl has to convert away, then it can easily use Unix epoch. CN Also, you might want to convert between other epochs; what if you get an CN epoch value FROM Mac OS on a Unix box, and want to convert it? That's a different problem than we are trying to solve. This is a wider problem then a fixed epoch for perl. Let's turn this around. What if we are on a platform that doesn't use perl's epoch and we need to write a value to a file? I think I've just gotten very confused. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch
Bart Lateur [EMAIL PROTECTED] writes: Now, on those platforms without 64 bit support, a double float has a lot more mantissa bits than 32, typically 50-something (on a total of 64 bits). This means that all integers with up to more than 50 significant bits can exactly be represented. That would be a lot better than the current situation of 32 bits. Everything I've heard from anyone who's done work on time handling libraries is that you absolutely never want to use floating point for time. Even if you think that the precision will precisely represent it, you don't want to go there; floating point rounding *will* find a way to come back and bite you. Seconds since epoch is an integral value; using floating point to represent an integral value is asking for it. As an aside, I also really don't understand why people would want to increase the precision of the default return value of time to more than second precision. Sub-second precision *isn't available* on quite a few platforms, so right away you have portability problems. It's not used by the vast majority of applications that currently use time, and I'm quite sure that looking at lots of real-world Perl code will back me up on this. It may be significantly more difficult, complicated, or slower to get at on a given platform than the time in seconds. I just really don't see the gain. Sure, we need an interface to sub-second time for some applications, but please let's not try to stuff it into a single number with seconds since epoch. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch
At 17:47 -0400 2000.09.14, Chaim Frenkel wrote: "CN" == Chris Nandor [EMAIL PROTECTED] writes: CN No, that won't really work. When my offset from GMT changes for daylight CN savings time, it will break. The point of having a module is that epoch CN conversions are more complicated than that. For example, Mac OS epoch CN begins at Jan 1 1904 00:00:00 _local time_. That is why the timezone CN offset from GMT was passed to the Time::Epoch functions. I'm confused. How do you expect the program to know the timezone if the OS doesn't? I am not sure what you mean by "the program." If you mean perl, well, perl often doesn't. Figuring out the correct time zones is sometimes quite hard. And yes, sometimes the OS is completely lacking in knowledge of a time zone. If you'll note, the Time::Epoch example asked that the time zone differential be one of the arguments, because we don't want to rely on guessing (but we fall back to guessing if none is supplied). Assuming the OS does know, and perl can find out from the OS, then perhaps a variable would work. But I, for the most part, despise the idea of adding more global variables to Perl. I would much rather call a simple function. And if the program knows it and can track it, then we can hand off the responsibility to Perl. My program knows the timezone difference because I hardcoded it in. :) CN Also, you might want to convert between other epochs; what if you get an CN epoch value FROM Mac OS on a Unix box, and want to convert it? That's a different problem than we are trying to solve. I don't think so. What we are trying to solve is the problem of different system epochs. This is a wider problem then a fixed epoch for perl. Let's turn this around. What if we are on a platform that doesn't use perl's epoch and we need to write a value to a file? Yes. What if? That's what we're addressing. Right now, you need to use something like Time::Epoch to do a conversion, or you use a non-ambiguous representation, such as you get with Date::Manip (which, BTW, I believe is broken in respect to MacPerl's epoch; that is, I think I needed to convert to Unix epoch before doing something with it). -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch
"CN" == Chris Nandor [EMAIL PROTECTED] writes: This is a wider problem then a fixed epoch for perl. Let's turn this around. What if we are on a platform that doesn't use perl's epoch and we need to write a value to a file? CN Yes. What if? That's what we're addressing. Right now, you need to use CN something like Time::Epoch to do a conversion, or you use a non-ambiguous CN representation, such as you get with Date::Manip (which, BTW, I believe is CN broken in respect to MacPerl's epoch; that is, I think I needed to convert CN to Unix epoch before doing something with it). You misundertood me. You have to know several different facts. The current epoch, the machine epoch, the epoch that the file requires. I really don't see that we need more than what is the difference between the timestamp returned from the syscalls, and the unix (or whatever) epoch. If you want to adjust for timezones just calculate the constant. Which since you are giving it in HHMM format you might as well just calculate directly. So what am I missing. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
