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 kind
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, where's your sense of history? (As in
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, where's your sense of history? (As
(-internals removed from the CC list)
[EMAIL PROTECTED] writes:
All calendar systems are arbitrary.
Yup. So let's use Larry's birthdate-and-time as the epoch marker.
Seriously, stick with 1970 (if we need an arbitrary marker, no reason
it can't be a familiar one) and extend date/time values
Jonathan wrote:
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
[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 own epoch, like the
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 should stick to
something that
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 sense of history? (As in creating our own. :-)
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 1901?),
VMS' epoch zero is
"RA" == Russ Allbery [EMAIL PROTECTED] writes:
RA Is Perl currently using different epochs on different platforms? If so, I
RA can definitely see the wisdom in doing something about *that* and
RA off-loading the system-local time processing into modules (although I can
RA also see the wisdom
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:
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 completely
[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 start of a new 400 year
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/any other group of people who have their own
calendar that predates christianity/
Good point.
Unix epoch it is! :-)
-Nate
On Mon, Aug 14, 2000 at 06:13:13PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Maintain internal time in Modified Julian (not epoch)
How would this be stored? As a floating point number? What about
sub-second accuracy? To get seconds you'd need about 5.15 decimal
places (let's just
How 'bout 100ns ticks from base date, stored in a 64-bit number? That
We are going to have quads supported on all platforms, then? With
software emulation of our own if nothing else is available? I wouldn't
object, mind...
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special
On Mon, Aug 14, 2000 at 02:42:39PM -0400, Dan Sugalski wrote:
At 01:36 PM 8/14/00 -0500, Jonathan Scott Duff wrote:
On Mon, Aug 14, 2000 at 06:13:13PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Maintain internal time in Modified Julian (not epoch)
How would this be stored? As a
At 01:48 PM 8/14/00 -0500, Jarkko Hietaniemi wrote:
How 'bout 100ns ticks from base date, stored in a 64-bit number? That
We are going to have quads supported on all platforms, then? With
software emulation of our own if nothing else is available? I wouldn't
object, mind...
I'd like to
On Mon, Aug 14, 2000 at 03:01:48PM -0400, Dan Sugalski wrote:
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
On Mon, 14 Aug 2000, Nick Ing-Simmons wrote:
Jonathan Scott Duff [EMAIL PROTECTED] writes:
On Mon, Aug 14, 2000 at 06:13:13PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Maintain internal time in Modified Julian (not epoch)
There has to be _an_ epoch - even Caesar started
On Mon, Aug 14, 2000 at 02:28:29PM -0500, Jonathan Scott Duff wrote:
On Mon, Aug 14, 2000 at 03:01:48PM -0400, Dan Sugalski wrote:
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
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 mjdate() routine and thought it was at
the language
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
timekeeping method. It would be in Time::Local for
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% UNIX head. All I work on is UNIX
(thank
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 astronomical
reason
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 astronomical
reason IIRC.
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).
2. mjdate()
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
Tim Jenness [EMAIL PROTECTED] writes:
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
29 matches
Mail list logo
