RE: leap seconds in DateTime
Zefram wrote: Jim Monty wrote: Please explain this. I've always thought DateTime *does* handle leap seconds correctly. DateTime `knows', falsely, that there will be no more leap seconds after the last one that it knows of. You can see this, for example, by asking what is the UTC time N seconds after a given UTC time. Using DateTime 0.4304, for example, I get these correct results: $ perl -MDateTime -we '$dt=DateTime-new(year=2008, month=12, day=30, time_zone=UTC);$dt-add(seconds=86400);print $dt,\n' 2008-12-31T00:00:00 $ perl -MDateTime -we '$dt=DateTime-new(year=2008, month=12, day=31, time_zone=UTC);$dt-add(seconds=86400);print $dt,\n' 2008-12-31T23:59:60 $ ... Uh-oh, I don't get the same results with DateTime 0.4304 and ActivePerl 5.8.8 on Windows XP: C:\perldoc -m DateTime | grep VERSION = $VERSION = '0.4304'; C:\perl -MDateTime -wle my $dt = DateTime-new(year = 2008, month = 12, day = 30, time_zone = 'UTC'); $dt-add(seconds = (60 * 60 * 24) ); print $dt; 2008-12-31T00:00:00 C:\perl -MDateTime -wle my $dt = DateTime-new(year = 2008, month = 12, day = 31, time_zone = 'UTC'); $dt-add(seconds = (60 * 60 * 24) ); print $dt; 2009-01-01T00:00:00 C:\ [Time elapses.] Oh, I think I see the problem: C:\perldoc -m DateTime::LeapSecond | grep VERSION = $VERSION = '0.05'; # last standalone distro was 0.03 C:\perldoc -m DateTime::LeapSecond | egrep -B 3 -A 3 ^2006 1996 Jan. 1 +1 1997 Jul. 1 +1 1999 Jan. 1 +1 2006 Jan. 1 +1 ) ); } C:\ [More time elapses.] I don't think this is a local problem. In other words, I see the proper entry for the next impending leap second (2009 Jan. 1 +1) missing from LeapSecond.pm on CPAN: http://search.cpan.org/src/DROLSKY/DateTime-0.4304/lib/DateTime/LeapSeco nd.pm It is, however, in leaptab.txt on CPAN: http://search.cpan.org/src/DROLSKY/DateTime-0.4304/leaptab.txt Hmm... -- Jim Monty (I apologize for the legal notice below.) html body p***/p pThe information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this email are subject to the terms and conditions expressed in the governing KPMG client engagement letter./p p***/p /body /html
Re: leap seconds in DateTime
Monty, James T wrote: Uh-oh, I don't get the same results with DateTime 0.4304 and ActivePerl 5.8.8 on Windows XP: In the changelog: |0.162003-08-06 | |[ IMPROVEMENTS ] | |- The XS code now implements leap second-related calculations. | However, this is only used on platforms where we can find a usable | finite() or isfinite() function/macro, so it isn't used on Win32. Looks like the XS picks up the leap second table from leaptab.txt, but the pure Perl needs to be edited manually and now isn't being tested by users who have XS functionality. -zefram
RE: leap seconds in DateTime
Zefram wrote: Jim Monty wrote: Uh-oh, I don't get the same results with DateTime 0.4304 and ActivePerl 5.8.8 on Windows XP: In the changelog: |0.162003-08-06 | |[ IMPROVEMENTS ] | |- The XS code now implements leap second-related calculations. | However, this is only used on platforms where we can find a usable | finite() or isfinite() function/macro, so it isn't used on Win32. Looks like the XS picks up the leap second table from leaptab.txt, but the pure Perl needs to be edited manually and now isn't being tested by users who have XS functionality. Gosh, I didn't realize I was using the pure Perl version of DateTime. In fact, I've always assumed I was using the XS version because I installed it using the ActiveState Perl Package Manager. Why would it do me like that? From now on, I'm going to compile modules myself, regardless how painful it is on Windows. Could this explain why, at times, I've observed what I thought was undue slowness with DateTime? Is there a way to determine exactly which version of the module one is using? -- Jim Monty (I apologize for the legal notice below.) html body p***/p pThe information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this email are subject to the terms and conditions expressed in the governing KPMG client engagement letter./p p***/p /body /html
Re: leap seconds in DateTime
On Wed, 1 Oct 2008, Zefram wrote: So, anyway, most users don't need precise leap second handling. Many, presumably, do need (approximate) calculations on times in the future and before 1972. It is sensible for them that vague-regular-UT is used in those eras. But they'd be better served by a *consistent* vague-regular-UT model. No one is well served by the mixed model: it's vague *ir*regular UT, not guaranteeing any of the useful things that its component models do. DateTime tries to be everything to everyone, and suffers from the resulting contradictions. It's all tradeoff. The more variations of correctness DateTime offers, the more the end user of the module has to understand in order to make the module do something. In other words, more options means a bigger API which means more docs, more examples, more stuff to learn about before you can get started. It's already bad enough with having to decide how to do date math. Specifically, to really do date math in an informed way, you first need to decide on what time zone to do it in (floating, UTC, or local). If you're using anything but floating, you then need to think about what order the math is done in (second then days, or the reverse?). In the case of UTC and leap seconds, most people probably don't care or _need_ to care, so DateTime works just fine. For those folks who need to care, they probably know what to look for, and can use Time::UTC. This is different from date math, where most folks know enough to expect _some_ answer but not enough to know the nuances. They try to use DateTime, maybe get a confusing answer (depending on their expectations), and can then read the docs explaining all the painful things they need to think about. If I had it to do all over again, I might consider just ignoring leap seconds altogether. It'd certainly make the internals much simpler. Then for people who actually care, there would be a separate module that handled leap seconds (and maybe _not_ time zones). I guess we'll see what happens for Perl 6. -dave /*== VegGuide.Org Your guide to all that's veg ==*/
Re: leap seconds in DateTime
Dave Rolsky wrote: If I had it to do all over again, I might consider just ignoring leap seconds altogether. It'd certainly make the internals much simpler. Then for people who actually care, there would be a separate module that handled leap seconds (and maybe _not_ time zones). I guess we'll see what happens for Perl 6. On that note, I have some recommendations for DateTime.pm development, which are inspired by my efforts to implement its functionality in my Muldis D language for databases. I've made a point of having clear separation of concerns in order for the date-time functionality to be both exactly deterministic, do exactly what people want, and avoid complexity. My central recommendation is to fully separate the representation of a date-time from any operations that convert data to or from that representation, and also separate out any date-time math operations. The object representing a date-time value should be both exact and flexible, letting users specify component-wise exactly the date/time they want, to any degree of precision (why limit to nanoseconds?, and Perl 6's built-in get-current-datetime returns a non-integer); it would be capable of representing leap-second values, though users don't actually have to store these if they don't want to. Likewise with duration values. Furthermore, you should have separate classes for floating and non-floating datetimes, or otherwise separate out things that conceptually shouldn't be mixed. Separately, have multiple versions of datetime operators, each one for the semantics you want, for example a separate version that respects known leap seconds from one that simply treats all days as being 86400 seconds; or you have a separate version that adds days before months versus months before days. Or you don't need actual separate operators, but just operators that are customizable with extra arguments to specify behaviour. The point here then is that every user gets behaviour that is deterministic, easier to understand, and easier to reliably implement and test. Separately you have multiple or customizable operators for importing or exporting data between component-based datetimes and other formats. But that said I'm much more interested in the previous 2 paragraphs than this. -- Darren Duncan
