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
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
> 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
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
>> 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.
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
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
At 09:25 AM 8/15/00 -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, where's your sens
On Tue, Aug 15, 2000 at 09:45:55AM -0700, Nathan Wiger wrote:
> I don't know about this. Sounds cool, but I think we should stick to
> something that somebody somewhere uses already. Of course, something
> standard like 0 AD isn't bad.
Standard for whom? I bet there are *millions* of Jews for wh
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
Larry Wall wrote:
>
> Oh, gee, where's your sense of history? (As in creating our own. :-)
> Maybe we should invent our own epoch, like the year 2000. Or use a
> really standard one, like the year 0 AD (aka 1 BC).
I don't know about this. Sounds cool, but I think we sho
[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, where's your sense of history? (As in creating our own. :-)
Maybe we should invent our
On Tue, Aug 15, 2000 at 08:44:48AM -0700, Nathan Wiger wrote:
> There seems to be a groundswell against this idea, which is fine by me
> (heck, just because it's my idea doesn't me it's a GOOD one!).
>
> Here's a different proposal, same vein: "Standardize a
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 portable.) MacOS' epoch zero is 1900 (or was it 1901?),
> VMS&#
On Mon, Aug 14, 2000 at 08:40:32PM -0700, Nathan Wiger wrote:
> No, but currently Perl IS forcing Windows, Mac, and BeOS users to
> understand what the UNIX epoch is.
So you're proposing that rather than give one platform (unix) an
advantage, we force all platforms to use some other
At 10:56 PM 8/14/00 -0500, 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 portable.) MacOS' epoch zero is 1900 (or was it 19
nto modules (although I can
RA> also see the wisdom in leaving well enough alone). But why not go with
RA> the most commonly used and most widely analyzed epoch?
Folks, the only problem that everyone seems to be arguing about is
what the EPOCH is. Who cares what the epoch is?
Create $Perl::
ltime() and gmtime().
Agreed.
I guess I don't really care what we use for an epoch for our sub-second
interface; I just don't see MJD as obviously better or more portable. I'd
actually be tentatively in favor taking *all* of the time stuff and
removing it from the core, under the modul
On 14 Aug 2000, Russ Allbery wrote:
> Day resolution is insufficient for most purposes in all the Perl scripts
> I've worked on. I practically never need sub-second precision; I almost
> always need precision better than one day.
>
MJD allows fractional days (otherwise it would of course be us
> Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition,
> just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?),
1904 (if it matters).
Damian
> 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 00:00:00.00, for some astron
Nathan Wiger <[EMAIL PROTECTED]> writes:
>> Anyway, it doesn't matter; it's a lot more widely used than any other
>> epoch, and epochs are completely arbitrary anyway. What's wrong with
>> it?
> I think the "What's wrong with it?"
> Anyway, it doesn't matter; it's a lot more widely used than any other
> epoch, and epochs are completely arbitrary anyway. What's wrong with it?
I think the "What's wrong with it?" part is the wrong approach to this
discussion. Personally, I'm a 100
stems
programmers), as it's what time() returns, and pretty much any C
programmer will have used that at some point or another. It's also so
widespread as to be at least somewhat familiar to non-Unix programmers.
Anyway, it doesn't matter; it's a lot more widely used than an
On 14 Aug 2000, Russ Allbery wrote:
> Nathan Wiger <[EMAIL PROTECTED]> writes:
>
> > The idea would be twofold:
>
> >1. time() would still return UNIX epoch time. However, it
> > would not be in core, and would not be the primary
> >
Nathan Wiger <[EMAIL PROTECTED]> writes:
> The idea would be twofold:
>1. time() would still return UNIX epoch time. However, it
> would not be in core, and would not be the primary
> timekeeping method. It would be in Time::Local for
> compatibility
On Mon, 14 Aug 2000, Nathan Wiger wrote:
>1. time() would still return UNIX epoch time. However, it
> would not be in core, and would not be the primary
> timekeeping method. It would be in Time::Local for
> compatibility (along with localtime and gmtime).
>
> > I'm not sure anyone does that much in the way of time/date work that it'd
> > make a difference. Besides, we're talking internal here--time() may still
> > return Unix epoch seconds for compatibility reasons.
>
> Blah! I saw the prosal for an mjdat
39 matches
Mail list logo
