Dave Rolsky wrote:
>>Which is why I started writing much plainer date-handling modules.
>
>Modules which while interesting are unlikely to be comprehensible to most
>folks.
Are they really *incomprehensible* to most people? But I didn't aim
them at "most people" as you describe them. I wrote th
On Tue, 18 Jul 2006, Zefram wrote:
I think it's a very important architectural issue. To my mind a date
(or date+time) exists quite independently of calendars. Each calendar is
merely a way of representing these dates. The DateTime way makes it look
like the expression of the date is part of
Joshua Hoblitt wrote:
>How is it buggy?
In the same sense that it'll be fixed by a future version's knowledge
of each future leap second. You not-seriously suggested that the
incompleteness of the leap second list was merely a bug that would be
fixed in a future version.
In reality it's not a bu
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 per
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 da
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 tim
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, rega
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
Eugene van der Pijll wrote:
>But have you looked at the DT::Format::Epoch example in my first mail yet?
Your example of usage made it clearer. I'm not sure what to make of
it yet. I need to ponder it some more.
There's a basic difference in our approaches to JDs here. You've
implemented CJD as
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, regardless of day l
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 s
Zefram schreef:
> 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 will take a look.
> >I don't understand why you say DT does not know about CJDNs.
>
> Did you notice that JD refers to Universal Time but CJD
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
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:
> 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
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 second
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
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 synce
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
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 D
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 h
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; arithmetic-f
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?
>
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
interpola
I've written a couple of Perl modules that do low-level date stuff,
way below the high-level DateTime concept. I'd appreciate a review
of my modules by the date experts on this list. The modules are
Date::JD, which does conversions between several flavours of Julian
Date, and Date::ISO8601, which
25 matches
Mail list logo
