Dan Sugalski <[EMAIL PROTECTED]> wrote:
> However, note that the base date is different on Windows ...
... and depending on the compiler version and vendor. This is a snippet
from an app, which of course was written when I was younger, but this
was the code that accumulated to get a "base date" j
At 18:46 +0100 3/3/04, Jos Visser wrote:
>Nahhh.... Epoch should be 1-1-1970 at 12:00am midnight, *but* we will
>have to allow for negative time values so that we can span either side
>of eternity...
That's not so strange. On of the, very few, things Microsoft has done right is to
t getting into the "What should our base time for the
>> epoch be" arguments, I'll warn you that the answer if I have to make
>> one is probably Nov 17, 1858 at midnight, give or take a bad memory,
>> and our time value'll be a 64-bit integer. So think ca
quot;What should our base time for the
> >> epoch be" arguments, I'll warn you that the answer if I have to make
> >> one is probably Nov 17, 1858 at midnight, give or take a bad memory,
> >> and our time value'll be a 64-bit integer. So think carefully b
At 6:46 PM +0100 3/3/04, Jos Visser wrote:
On Wed, Mar 03, 2004 at 11:37:09AM -0500 it came to pass that Dan
Sugalski wrote:
FWIW, if we start getting into the "What should our base time for the
epoch be" arguments, I'll warn you that the answer if I have to make
one is probab
On Wed, Mar 03, 2004 at 11:37:09AM -0500 it came to pass that Dan Sugalski wrote:
>
> FWIW, if we start getting into the "What should our base time for the
> epoch be" arguments, I'll warn you that the answer if I have to make
> one is probably Nov 17, 1858 at m
On Tue, 30 Jan 2001, Nathan Wiger wrote:
> Jarkko Hietaniemi wrote:
> >
> > As I said the problem isn't the p52p6 doing that kind of transformation.
> > The problem is someone familiar with perl5 writing code in perl6:
> >
> > if (my $fh = open(">/tmp/$$".time())) {
> >
> > and later
ng and burning because some other place expects
> to find a filename of the form /^\d+\d+$/, or someone printing into log files
> like this
>
> print LOG time() . ": gorkulator borked. Please investigate."
>
> and someone splitting on /\./, etc.
Good point, this
ix systems currently convert UTC into
seconds since epoch without adjusting for any leap seconds.
All Unix clocks are natively TAI, given that they don't adjust for leap
seconds and tick forward one second every second. However, since most
people actually keep UTC or a time zone based on U
- Original Message -
From: "Perl6 RFC Librarian" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, September 28, 2000 14:37
Subject: RFC 99 (v4) Standardize ALL Perl platforms on UNIX epoch
> The issue is still open as t
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Standardize ALL Perl platforms on UNIX epoch
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 14 Aug 2000
Last Modified: 28 Sep 2000
Mailing List: [EMAIL PROTECTED]
Numb
Nathan Wiger wrote:
>
> I think we should definitely maintain this in UTC, since this is how
> UNIX works natively. If we're standardizing on the UNIX epoch we should
> standardize on UTC clock as well.
Blech. Now I'm not sure after re-reading the thread starting
Russ Allbery wrote:
>
> Is Perl keeping UTC or TAI? If we're standardizing on an epoch, we should
> also standardize on a clock; the difference is over ten seconds.
I think we should definitely maintain this in UTC, since this is how
UNIX works natively. If we're standa
he hardware clock. It has to
CN> do with what the Mac OS API returns for seconds since epoch. The
CN> difference from GMT, or the difference from anything, cannot be hardcoded,
CN> because it is dynamic, depending on what timezone you are in at the moment.
What sets the timezone? And can
At 16:09 -0700 2000.09.19, Russ Allbery wrote:
>Was there any resolution as to how one obtains the offset between the
>system clock and the Unix epoch clock on a platform like Mac where
>apparently the system clock is in local time and it may be difficult to
>determine the time zone o
On 20 Sep 2000 13:03:22 -0700, Russ Allbery wrote:
>It's not a hardware problem; the hardware clock just keeps a time. It has
>no concept of time zones.
I thought later on that I wrote this the wrong way. What I ment was: the
guys who did the interface to the hardware.
>It's a software problem
Bart Lateur <[EMAIL PROTECTED]> writes:
> This is bad. That system is broken. ;-) I guess that it's the same
> situation on MS-DOS, since there the hardware clock is usually set to
> local time. It could even happen on Win32?!?
> This surely was a bad design decision from the hardware guys. Very
At 13:23 +0200 2000.09.20, Bart Lateur wrote:
>This surely was a bad design decision from the hardware guys. Very
>shortsighted.
I don't know if it has anything to do with the hardware clock. It has to
do with what the Mac OS API returns for seconds since epoch. The
difference from
On Mon, 18 Sep 2000 11:42:50 -0400, Chris Nandor wrote:
>>But the OS's idea of the epoch is global!
>
>No, it isn't! On Mac OS, I can change my epoch by changing my time zone.
>If it is harcoded into Config.pm, I am fucked.
This is bad. That system is broken. ;-) I
At 11:21 -0400 2000.09.18, Chaim Frenkel wrote:
>CN> I don't think you understand ... if you use $ENV{TZ}, at least it can be
>CN> changed for each user, for when you change time zones, DST, etc. For
>CN> Config.pm, you have to edit a global value. Ick.
>
>But
One of the major outstanding issues is still exactly what clock Perl
intends to keep and return from the time command. There has been some
discussion of the difficulties in obtaining the Unix epoch on platforms
where the native system clock is not using the Unix epoch; Nathan, could
you update
At 9:08 -0700 2000.09.18, Nathan Wiger wrote:
>Chris Nandor wrote:
>>
>> >just assume "All Perl core functions should return objects", and hence
>> >the reason I wrote RFC 73. ;-)
>>
>> And it would make me stop using Perl faster than your object method could
>> be resolved.
>
>Is your concern one
Chris Nandor wrote:
>
> >just assume "All Perl core functions should return objects", and hence
> >the reason I wrote RFC 73. ;-)
>
> And it would make me stop using Perl faster than your object method could
> be resolved.
Is your concern one of?
1. Speed
2. Bloat
3. Excess burden o
or when you change time zones, DST, etc. For
CN> Config.pm, you have to edit a global value. Ick.
But the OS's idea of the epoch is global!
>> Just a function/variable that would contain the offset from machine/os
>> system epoch to unix (or universal) epoch.
CN> But ther
At 11:56 -0400 2000.09.17, Chris Nandor wrote:
>At 11:10 -0700 2000.09.16, Nathan Wiger wrote:
>>Now, one thing that should probably be explored is creating a time
>>object, similar to the date object specified in RFC 48. In fact, I'd
>>just assume "All Perl core functions should return objects",
At 11:10 -0700 2000.09.16, Nathan Wiger wrote:
>Now, one thing that should probably be explored is creating a time
>object, similar to the date object specified in RFC 48. In fact, I'd
>just assume "All Perl core functions should return objects", and hence
>the reason I wrote RFC 73. ;-)
And it w
> Standardize ALL Perl platforms on UNIX epoch
I've seen lots of discussion on this, and there have been 2 previous
versions worth of discussion as well. The first version of this was
actually entitled:
"Maintain internal time in Modified Julian (not epoch)"
but that got
At 17:11 -0400 2000.09.15, Chaim Frenkel wrote:
>>>>>> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
>
>>> This new module to cover your feature would require that it know every
>>> known epoch and timesystem (or at least the useful ones.)
>>>>> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
>> This new module to cover your feature would require that it know every
>> known epoch and timesystem (or at least the useful ones.) Something
>> this domain knowledgable shouldn't be
gt; * You might need to convert from an epoch other than your native
>CN> one, whether it is a different time zone, or a different epoch
>CN> entirely; with a function, you can easily take care of these
>CN> problems * Global variables suck
>
>That is beyond the scope of t
see how the three variables wouldn't cover the spectrum.
CN> * You might need to convert from an epoch other than your native
CN> one, whether it is a different time zone, or a different epoch
CN> entirely; with a function, you can easily take care of these
CN> problems * Global
On Fri, 15 Sep 2000 11:58:08 -0400 (EDT), Andy Dougherty wrote:
>[Aside: Does this mean that make(1) is useless for one hour after
>standard time resumes?]
That'll teach you. You shouldn't be programming in the middle of the
night.
--
Bart.
On Fri, 15 Sep 2000, Chris Nandor wrote:
> You can only avoid breakage with current scripts if you make no changes to
> the current facilities (which is what Andy proposed).
Well I have to admit that I was unaware that on Mac and VMS (without the
wizardry in vms/vms.c) the value returned by time
n_seconds
> = time_in_unix_epoch_seconds
But again, I don't know what you are trying to say. Are you saying we
should have some global "constant"? If so, you still have problems:
* We do not know if it will always be this simple for every platform
* You might need to conve
On Thu, 14 Sep 2000 19:19:34 -0400, Chris Nandor wrote:
>And yes, sometimes the OS is completely lacking in knowledge of a
>time zone.
This problem isn't new. Currently, Perl must know the timezone to be
able to correctly generate gmtime() and localtime().
--
Bart.
At 22:19 -0400 2000.09.14, Chaim Frenkel wrote:
>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.
Beats me. I am not sure whether or not you have a point, and if so,
>>>>> "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
>>
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 h
resent 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
with a few others, but in
strictly conforming C, the only thing you can do with a time_t is pass it
to one of the conversion functions or use difftime to compare it to
another one.
> So subtracting them may not give you seconds since any epoch (that's
> what the difftime() is for;
>>>>> "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 tha
On 13 Sep 2000 14:22:30 -0700, Russ Allbery wrote:
>I think it should be specified that the return value is seconds since Unix
>epoch and the storage size be left unspecified, from the language
>perspective. On those platforms that support it, using 64 bits is
>obviously a good id
At 11:59 -0400 2000.09.14, Andy Dougherty wrote:
>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
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 can
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
betwee
At 11:05 -0400 2000.09.14, Philip Newton wrote:
>You have another assumption up there: that time_t == signed long (since
>you're printing it with %ld) with a resolution of seconds (since you say
>"%ld seconds"). ISO/IEC 9899:1999 (draft C standard, the only C standard-y
True. In Mac OS, time_t i
ssues. 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 second
art = 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
t;, and that "the range and precision representable in clock_t and
time_t are implementation-defined". So subtracting them may not give you
seconds since any epoch (that's what the difftime() is for; it explicitly
gives you seconds of difference, as a double), and even if you knew it
did
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
At 10:08 -0400 2000.09.14, Andy Dougherty wrote:
>This is not a simple either-or. 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 th
rogram won't print '5', then I don't see how
changing the epoch could possibly help. More radical surgery is required.
If you mean the above program _will_ print '5', then I'd say the system
has a fine time() function, whatever epoch it uses, and I think perl
s
al 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
()-$Perl::EpochOffset;
No, that won't really work. When my offset from GMT changes for daylight
savings time, it will break. The point of having a module is that epoch
conversions are more complicated than that. For example, Mac OS epoch
begins at Jan 1 1904 00:00:00 _local time_. That is
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> 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)
The more commonly-used ISO format is the extended format rather than t
> "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 progr
rn value is seconds since Unix
epoch and the storage size be left unspecified, from the language
perspective. On those platforms that support it, using 64 bits is
obviously a good idea.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
At 16:04 -0400 2000.09.13, Andy Dougherty wrote:
>> If we standardize on the Unix epoch (although possibly with 64 bits), this
>> won't be an issue for the overwhelming majority of users.
>
>Are you sure? Won't this affect Windows as well as Mac users? There are
&g
On Wed, 13 Sep 2000, Chris Nandor wrote:
> At 14:30 -0400 2000.09.13, Andy Dougherty wrote:
> >2. (RFC 99 way): If you store the time from within a perl program and
> >then read it with a C program on the SAME OS, then you might have a
> >problem.
>
> That is what
At 14:30 -0400 2000.09.13, Andy Dougherty wrote:
>2. (RFC 99 way): If you store the time from within a perl program and
>then read it with a C program on the SAME OS, then you might have a
>problem.
That is what Time::Epoch should address, I hope.
If we standardize on the Unix epoch
On Wed, 13 Sep 2000, Michael G Schwern wrote:
> > 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).
> Color me obvious, but could you discuss some of the practic
At 5:34 -0400 2000.09.13, Michael G Schwern wrote:
>On Wed, Sep 13, 2000 at 07:10:30AM -, Perl6 RFC Librarian wrote:
>> Currently, internal time in Perl is maintained via C, which is
>> highly system-dependent. On some systems, this is relative to the UNIX
>> epoch, while
On Wed, Sep 13, 2000 at 07:10:30AM -, Perl6 RFC Librarian wrote:
> Currently, internal time in Perl is maintained via C, which is
> highly system-dependent. On some systems, this is relative to the UNIX
> epoch, while others use their own epochs (MacPerl uses 1904, for
> exampl
On 13 Sep 2000 07:10:30 -, Perl6 RFC Librarian wrote:
>In addition, a C function should be added which provides access
>to the native epoch/system time. For simplification, it might be best if
>this C function remain the basis for other library-related
>functions, such as C,
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Standardize ALL Perl platforms on UNIX epoch
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 14 Aug 2000
Last-Modified: 12 Sep 2000
Mailing List: [EMAIL PROTECTED]
Numb
73, "All Perl core
functions should return objects", gets adopted. Then we could easily
have time() return an object which, when in a numeric or string context,
evaluates to the UNIX epoch seconds. But it could easily have object
methods like:
$t = time; # Generate time object
print $
>>>>> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> This is good for comparison but bad for math. Epoch seconds are
NT> good for both. That's why *I* use them. You can continue to use
NT> ISO mumble and have it work for you. I'm n
Chris Nandor wrote:
> Interesting. I still think we should have our own real 64-bit time,
> though, since not all platforms will be 64 bit (although by 2020 they may
> be), and perhaps not all of them will be LP64 (and I confess to not know
> what that stands for :).
Simple - LP64 = 'Longs and
At 11:05 +0100 2000.08.23, Alan Burlison wrote:
>Be aware that perl5 already will support a 64-bit time_t if it is
>compiled as a 64 bit application. This is because time_t is defined as
>long, and on LP64 platforms (the majority of 64 bit platforms are I
>think), long becomes 64 bit when apps ar
Russ Allbery wrote:
> > 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.
Be aware that perl5 already will support a 64-bit time_t if it is
compiled as a 64 bit application. This is because time_t
On Sun, 20 Aug 2000, Chris Nandor wrote:
> At 15:02 -1000 2000.08.19, Tim Jenness wrote:
> >I'm of the camp that feels perl should have a fixed epoch rather than the
> >epoch of the underlining OS. Furthermore, I can understand that the OS
> >epoch can also be importa
At 15:02 -1000 2000.08.19, Tim Jenness wrote:
>I'm of the camp that feels perl should have a fixed epoch rather than the
>epoch of the underlining OS. Furthermore, I can understand that the OS
>epoch can also be important when looking outside of perl. Thinking this
>over for a
I'm of the camp that feels perl should have a fixed epoch rather than the
epoch of the underlining OS. Furthermore, I can understand that the OS
epoch can also be important when looking outside of perl. Thinking this
over for a while it occurred to me that time() currently has no argument
This discussion should be on the -datetime sublist. Please do not
discuss this RFC any further on the main language list.
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone:
erstanding 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).
>>>>
Here are some comments from Matthias Neeracher, the MacPerl author, and a
few comments from me.
>To: Chris Nandor <[EMAIL PROTECTED]>
>Subject: Re: Fwd: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
>Date: Wed, 16 Aug 2000 07:31:25 +0200
>From: Matthias Ulrich
On 16 Aug 2000, Chaim Frenkel wrote:
> > "BB" == Buddha Buck <[EMAIL PROTECTED]> writes:
>
> BB> I am assuming that the system clocks are set accurately to UTC (or some
> BB> derivative, like (US) Eastern Standard Time). UTC is what time-servers
> BB> report. UTC has leap seconds, which a
wo digits is enough :-)
>
And the 2038 deadline won't hit us in 2038, it will do it evil work long
before that.
I have been hit by it some years ago, trying to calculate the 67'th
birthday of a person that was 18 years old.
Solution: switch to the Date::Calc module for all date calc
> Either one or both of:
> Perl <-> Perl cross system will break.
> Perl <-> other program same system will break.
>
> Pick your poison. I'd rather have cross system break. But if the
> epoch were available then an adjustment could be made int
and access times of
BB> @files to "now".
With or without a translation?
BB> sleep(), select() both take intervals. The time scale is irrelevant.
It does matter, depending upon what an external system may supply.
BB> Will events need time stamps, intervals, or other (please speci
At 11:17 PM 8/15/00 -0400, Chaim Frenkel wrote:
> >>>>> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
>
>NT> Chaim Frenkel writes:
> >> Why? What is the gain? Perl only runs on the local machine.
>
>NT> Epoch seconds are a conve
J. David Blackstone wrote:
> I always treat the return value of time() as a black-box value. I
>can perform specific actions on it, such as feeding it to localtime()
>or adding relative time intervals to it, such as a year of seconds.
>But I do not allow myself to look at that value. I was ki
At 10:37 AM 8/16/00 -0400, Chaim Frenkel wrote:
> >>>>> "BB" == Buddha Buck <[EMAIL PROTECTED]> writes:
>
>BB> If we have to pick and epoch in an OS-neutral way, I think I for one
>BB> would be happy with something like this in the docs for the
be 11:59:59 or
BB> 12:00:01 as well. And there is no way to know that ahead of time.
Hmm, there are negative leap seconds?
BB> If we have to pick and epoch in an OS-neutral way, I think I for one
BB> would be happy with something like this in the docs for the time
BB> functio
On Wed, Aug 16, 2000 at 09:49:36AM -0400, Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and Jonathan Scott Duff <[EMAIL PROTECTED]
> > whispered:
> | Um, it's not guaranteed to blow up in 2038. That's an implementation
> | detail. IF we implement our time values as 64-bit integer
Lightning flashed, thunder crashed and Jonathan Scott Duff <[EMAIL PROTECTED]
> whispered:
| Um, it's not guaranteed to blow up in 2038. That's an implementation
| detail. IF we implement our time values as 64-bit integers (for
| instance), we'll long out-live the 2038 deadline.
I don't know ab
> On Tue, Aug 15, 2000 at 09:25:34AM -0700, Larry Wall wrote:
> > [EMAIL PROTECTED] writes:
> > : Yep. Or more generally "Standardize Perl on all platforms to one
> > : common time epoch" and reccommend the Unix epoch since it's so
> > : widespread.
On Tue, Aug 15, 2000 at 09:25:34AM -0700, Larry Wall wrote:
> [EMAIL PROTECTED] writes:
> : Yep. Or more generally "Standardize Perl on all platforms to one
> : common time epoch" and reccommend the Unix epoch since it's so
> : widespread. :-)
>
> Oh, gee, wh
Please take this discussion to perl6-language-datetime. Thanks!
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664
st
>> start with Jan 1, 2K?
>
>This works, provided epoch seconds are stored in some form of big
>integers (either arbitrary precision, or 64-bit). The epoch change
>would then be fine by me. But epoch changes don't solve the 2038
>problem, Unix already tried that before the move
On Tue, 15 Aug 2000, Nathan Wiger wrote:
> Jarkko Hietaniemi wrote:
> >
> > > Is Perl currently using different epochs on different platforms? If so, I
> >
> > Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition,
> > just to be port
that
navigation using sextants wanted to keep things
as simple as possible, so easily dividible numbers
were quite desirable.)
so its all arbitrary.
but most people developing perl use the gregorian
calendar. and it seems to be fairly widespread
as far as calendars go. and in the spirit of
&qu
>> Is Perl currently using different epochs on different platforms? If so, I
>
> Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition,
> just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?),
> VMS' epoch zero is 17-NOV-1858 0
c.)
I would really rather not see this change, or see the number
expressed in seconds. (MJD as seconds would really amount to just
moving the epoch, and I don't think that would make anyone happy.)
I still lean towards thinking that anything involving a date should
be pushed out into a m
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 &
[EMAIL PROTECTED] writes:
> Midnight, Jan 1, 2000, Greenwich time
>
> seems like a good candidate.
<http://www.naggum.no/lugm-time.html> have found 2000-03-01 to be a
good epoch. It makes -mm-dd decoding and leap year calculations
cheaper/simpler as it is the closest sta
At 02:23 PM 8/15/00 -0400, [EMAIL PROTECTED] wrote:
>Modified Julian Day 0 thus started on 17 Nov 1858 (Gregorian) at 00:00:00
>UTC.
>(somebody threw that date out, It appears to be purely
>arbitrary rather than based on some celestial event)
Not arbitrary at all. From: http://www.kgb.com/calend.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Standardize ALL Perl platforms on UNIX epoch
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 14 Aug 2000
Last-Modified: 15 Aug 2000
Version: 2
Mailing List: [EMAIL PRO
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I think I'd snag a date after the last western country went Julian, just to
> avoid some of the less fun time conversion issues. (How long ago Jan 1,
> 1690 was depends on what country you're in)
I think you mean
Jonathan Scott Duff wrote:
>
>> standard like 0 AD isn't bad.
>
> Standard for whom? I bet there are *millions* of Jews for whom "0 AD"
> is meaningless. s/Jews/ calendar that predates christianity>/
Good point.
Unix epoch it is! :-)
-Nate
1 - 100 of 120 matches
Mail list logo
