Is all that stuff just a reinvention of the wheel? What's the value add
over DateTime and the zillions of other date/time modules already on CPAN?
I have to admit I haven't really looked at your code in depth but I
don't see how you can accurately be calculating TT/etc. without doing an
Oops - I made a typo. Replace TT with UT1. (TT is trivial to calculate).
-J
--
On Sun, Jul 16, 2006 at 10:25:51PM -1000, Joshua Hoblitt wrote:
Is all that stuff just a reinvention of the wheel? What's the value add
over DateTime and the zillions of other date/time modules already on CPAN?
Joshua Hoblitt wrote:
Is all that stuff just a reinvention of the wheel?
Yes, but this time it's round.
What's the value add
over DateTime and the zillions of other date/time modules already on CPAN?
Three things: API isolation;
Joshua Hoblitt wrote:
Oops - I made a typo. Replace TT with UT1.
I haven't written any code that tackles UT1 yet. My interests lie
firmly in atomic (and platonic) timekeeping. Watching a planet rotate
is too much like getting my hands dirty. Though I did write Time::UTC,
because I wanted to
Zefram schreef:
Joshua Hoblitt wrote:
Is all that stuff just a reinvention of the wheel?
Yes, but this time it's round.
DateTime's wheels are round as well; it's just that there's a whole lot
of machinery attached to the wheels which you may not care for. If there
is any instance where
Eugene van der Pijll wrote:
is any instance where DateTime gets it wrong, please let us know.
There's leap seconds, but I presume that's intentional. AFAIK DateTime
operates correctly within its designed limits.
priorities of DT have always been 1) correctness 2) ease of use 3)
efficiency, in
On Mon, Jul 17, 2006 at 05:42:29PM +0100, Zefram wrote:
There's leap seconds, but I presume that's intentional. AFAIK DateTime
operates correctly within its designed limits.
Entirely accidental, I assure you! They are part of UTC. Which in all
likely hood is what your system clock is synced
Zefram schreef:
Eugene van der Pijll wrote:
is any instance where DateTime gets it wrong, please let us know.
There's leap seconds, but I presume that's intentional. AFAIK DateTime
operates correctly within its designed limits.
Leap seconds are one of the things DateTime tries to get
Joshua Hoblitt wrote:
Entirely accidental, I assure you!
Oh dear.
There are two fundamental problems with DateTime's handling of leap
seconds: one pertaining to the future, and one pertaining to the past.
For future times, DateTime implicitly assumes that there will never be
another leap
Eugene van der Pijll wrote:
It's enough for my needs anyway.
Dangerous words. There certainly are users that need greater precision.
I recommend Math::BigRat, which you'll have noticed I'm quite a fan of.
Bignums mean never having to think how big your floats are.
I don't
Zefram schreef:
There are two fundamental problems with DateTime's handling of leap
seconds: one pertaining to the future, and one pertaining to the past.
For every future leap second, there will be a version of DT that
handles it correctly. That the current implementation can not, is only
an
Eugene van der Pijll wrote:
We should not perhaps be calling our time scale
utc; but that would again be hard to explain to ordinary users.
I'm still trying to convince people that you can't just add 24*60*60 to
time() to add a day ..
Cheers!
Rick Measham
Eugene van der Pijll wrote:
For every future leap second, there will be a version of DT that
handles it correctly. That the current implementation can not, is only
an implentation problem :-).
Having the implementation thus permanently buggy seems like a bad idea.
Also, the version of DT that
Zefram schreef:
The only reason DateTime.pm (the module) seems to be the fundamental
class of DateTime (the project) is the name; it has no central role,
although there are a number of modules (e.g. formatting modules) that
have been written especially for DT.pm, because it is the most
Zefram wrote:
Rick Measham wrote:
I'm still trying to convince people that you can't just add 24*60*60 to
time() to add a day ..
That's one of the things you *can* do, unless you're starting in a leap
second (in which case time() is ambiguous). time() increases exactly
86400 per UTC day,
Rick Measham wrote:
how can you be
happy with adding 86400 seconds for a day (even in UTC) when leapseconds
make it ambiguous?
Oh, I'm not happy with it. time_t is not suitable for serious
timekeeping. It's just that if one *is* using
Eugene van der Pijll wrote:
Importantly, there are no calendar-less datetime objects. One may see
this as an important difference between your approach and DateTime's;
one may also see it as an implementation detail.
I think it's a very important architectural issue. To my mind a date
(or
On Mon, Jul 17, 2006 at 10:35:39PM +0100, Zefram wrote:
Eugene van der Pijll wrote:
For every future leap second, there will be a version of DT that
handles it correctly. That the current implementation can not, is only
an implentation problem :-).
Having the implementation thus permanently
18 matches
Mail list logo
