On Mon, 3 Feb 2003 [EMAIL PROTECTED] wrote:
There is something else to consider. What does a timestamp of May 5,
1776, 4:16:23 PM actually _mean_? For May 5, 1976, 4:16:23 PM,
it's clear which point in time we mean when we have the timezone.
But for dates 200 years ago, it isn't so clear.
On Tue, Jan 28, 2003 at 02:37:31PM +1100, Rick Measham wrote:
There are two time periods that do not change: Years (time the earth takes
to travel around the sun) and Days (time the earth take to spin one complete
revolution).
But they do change. If the length of a day was constant, we would
[EMAIL PROTECTED] (Rick Measham) wrote:
There are two time periods that do not change: Years (time the
earth takes to travel around the sun) and Days (time the earth
take to spin one complete revolution). I'd suggest that these
the the two values that DateTime keeps internally. The 'year'
On Mon, 27 Jan 2003, Peter J. Acklam wrote:
[EMAIL PROTECTED] (Rich Bowen) wrote:
On Sun, 6 May 2001 03:35:15 +0530, Abhijit Menon-Sen said:
Have you seen the TAI64* formats at URL:http://cr.yp.to/time.html?
(I am supposedly writing Time::TAI64.)
Hmm. attosecond accuracy? What
On Tue, 28 Jan 2003, Peter J. Acklam wrote:
[I know this is a very old posting, but I just can't resist
commenting it since it is about the base time format.]
It seems a little irrelevant, and perhaps even unfair, to start
rebutting comments that I made going on 2 years ago. A lot has happened
On Tue, 28 Jan 2003, Peter J. Acklam wrote:
[EMAIL PROTECTED] (Eugene Van Der Pijll) wrote:
Timestamps with a precision better than an attosecond are never
needed, as far as I know. Physicists work with as, ys and zs,
but only with time lengths or intervals, not with absolute time.
On Tue, 28 Jan 2003, Peter J. Acklam wrote:
[EMAIL PROTECTED] (Rick Measham) wrote:
There are two time periods that do not change: Years (time the
earth takes to travel around the sun) and Days (time the earth
take to spin one complete revolution). I'd suggest that these
the the two
On Tue, 28 Jan 2003, John Peacock wrote:
Tell you what; I'll write an implementation of my way (probably in XS) and we'll
compare. I think you're mistaken; your storage methods requires conversion for
all nontrivial operations (e.g. $dt-year), whereas mine only needs a conversion
when
Rich Bowen [EMAIL PROTECTED] wrote:
On Tue, 28 Jan 2003, Peter J. Acklam wrote:
[I know this is a very old posting, but I just can't resist
commenting it since it is about the base time format.]
It seems a little irrelevant, and perhaps even unfair, to start
rebutting comments that I
On Tue, 28 Jan 2003, Peter J. Acklam wrote:
I searched the archives and read a whole lot of postings, but
didn't find anything about what I wrote, so that's why I posted
it.
I wanted to join this project and contribute something, but first
I wanted to understand the reason behind some of
On Tue, 28 Jan 2003, Peter J. Acklam wrote:
Rich Bowen [EMAIL PROTECTED] wrote:
On Tue, 28 Jan 2003, Peter J. Acklam wrote:
[I know this is a very old posting, but I just can't resist
commenting it since it is about the base time format.]
It seems a little irrelevant, and perhaps
Dave Rolsky wrote:
Well, an XS implementation is quite likely to beat pure Perl, even if you
used RD days as well.
Don't tell anyone, but my first pass will be pure Perl, since I am still pretty
much an XS newbie...
John
--
John Peacock
Director of Information Research and Technology
Rowman
On Tue, 28 Jan 2003, John Peacock wrote:
Dave Rolsky wrote:
Well, an XS implementation is quite likely to beat pure Perl, even if you
used RD days as well.
Don't tell anyone, but my first pass will be pure Perl, since I am still pretty
much an XS newbie...
Hehe, that's fine. My guess
Dave Rolsky wrote:
Hehe, that's fine. My guess is that this is probably a much easier way to
write an XS module, since all you'll have to do is re-implement the same
logic in C, which leaves you free to _only_ think about all the low-level
C crap you have to deal with, as opposed to trying to
On Tue, 28 Jan 2003, John Peacock wrote:
Hehe, that's fine. My guess is that this is probably a much easier way to
write an XS module, since all you'll have to do is re-implement the same
logic in C, which leaves you free to _only_ think about all the low-level
C crap you have to deal
[EMAIL PROTECTED] (Rich Bowen) wrote:
On Sun, 6 May 2001 03:35:15 +0530, Abhijit Menon-Sen said:
Have you seen the TAI64* formats at URL:http://cr.yp.to/time.html?
(I am supposedly writing Time::TAI64.)
Hmm. attosecond accuracy? What real-world application really
needs that sort of
On Tue, 28 Jan 2003, Peter J. Acklam wrote:
[...] the fact that an ISO date can be expressed 6 different
ways, which makes ISO less attractive to me.
I don't see why this is relevant. A date may be represented in
many more than six ways, but as long as one picks one format and
everyone
On Tue, 28 Jan 2003, Eugene van der Pijll wrote:
On the other hand, I would like to be able to specify a date with a
precision of less than a day. For example, the date 1815, or
july 1974. But I'll write my own module around DateTime that can
handle these dates, if necessary.
You'll probably
Dave Rolsky wrote:
You'll probably need to write your own module around DateTime.pm. For
example, how do you handle adding 3 days to july 1974? How about 31 days?
I think that we should treat this as 3 + undef, since the date in question did
not specify a day, only a month. So I would
On 28/1/03 1:20 pm, John Peacock at [EMAIL PROTECTED] spake thus:
Hence, it would seem to me to make the most sense to store the basic DateTime
object as an array of (possibly undefined) periods: years, months, days,
hours,
minutes, seconds, etc. By doing it this way, instead of some sort of
On Mon, 27 Jan 2003, John Peacock wrote:
Hence, it would seem to me to make the most sense to store the basic DateTime
object as an array of (possibly undefined) periods: years, months, days, hours,
minutes, seconds, etc. By doing it this way, instead of some sort of days since
some epoch,
[EMAIL PROTECTED] (Eugene Van Der Pijll) wrote:
Timestamps with a precision better than an attosecond are never
needed, as far as I know. Physicists work with as, ys and zs,
but only with time lengths or intervals, not with absolute time.
That's probably true -- and the example I gave was,
22 matches
Mail list logo
