Bug #61535 for Date-Manip: DateCalc doesn't handle microsecond resolution

Tue Sep 21 17:23:05 2010 quanah.gibsonmount [...] gmail.com - Ticket created

Subject:

DateCalc doesn't handle microsecond resolution

Numerous applications track time with high precision. Unfortunately, DateCalc does not work with values that are so precise. For example, it returns nothing given these two values: 20100921205308.097631Z 20100921210750.621178Z I can get it to work by stripping everything from the decimal point onwards, but it would be nice for this to work correctly.

Wed Sep 22 07:53:09 2010 sbeck [...] cpan.org - Correspondence added

I've considered adding support for fractional seconds several times, but each time, I've decided that it was a bad idea. I'm certainly interested in adding functionality to Date::Manip (that should be pretty obvious based on the huge number of things that it DOES do), but I also try to be sensible. The more complex of a change, the more I try to limit it to changes that are of general use. My vision of Date::Manip is to be able to do everything that we (as humans) do with calendars and clocks. Although we do work with very precise times occasionally (especially in a scientific setting, or when we're timing how fast someone runs 100 meters), it is extremely rare that we mix dates with those specific times. It is almost unheard of for a normal person to care that an even occured on Jan 15, 2009 at 09:30:45.1253255 . Adding support for fractional seconds would be an extremely extensive change. I'd have to examine every single place that seconds were stored to see if it had to be modified... in other words, it would require an audit of the entire source code. Even worse, the addition would increase (perhaps not by a lot... but by something) the complexity of the source code. Any change that requires a complete audit of the source code really needs to be of general use before I'm willing to undertake it... and this isn't, so I'm afraid that my position is going to stay the same. Due to the rarity of the need for this functionality, the proper solution is to leave Date::Manip unchanged and add on some wrapper scripts which use Date::Manip to do the bulk of the operations and add the precision on afterwards. Sorry about that... but thanks for the suggestion.

Wed Sep 22 07:53:10 2010 The RT System itself - Status changed from 'new' to 'open'

Wed Sep 22 07:53:10 2010 sbeck [...] cpan.org - Status changed from 'open' to 'resolved'

Wed Sep 22 12:46:32 2010 quanah.gibsonmount [...] gmail.com - Correspondence added

On Wed Sep 22 07:53:09 2010, SBECK wrote: Show quoted text

> My vision of Date::Manip is to be able to do everything that we (as > humans) do with calendars and clocks. Although we do work with very > precise times occasionally (especially in a scientific setting, or when > we're timing how fast someone runs 100 meters), it is extremely rare > that we mix dates with those specific times. It is almost unheard of for > a normal person to care that an even occured on Jan 15, 2009 at > 09:30:45.1253255 .

It may be rare for humans to do this, but it is not rare for computers to do this. An general example of why this is important is when recording logs of changes in a computerized setting. There can be multiple modifications, for example, to a database in a single second. If that database is replicated, then knowing the time differential between events is extremely important. Limiting your module to just what humans do on an average basis is severely limiting in scope, particular given that what your module does is run on computers...

Wed Sep 22 12:46:33 2010 The RT System itself - Status changed from 'resolved' to 'open'

Wed Sep 22 13:08:23 2010 sbeck [...] cpan.org - Correspondence added

I'm not trying to say that it is not useful... merely that it isn't generally useful (at least not in the applications that Date::Manip is being used for). As a supporting piece of evidence of this... in the 15 years since Date::Manip was released, you're only the 2nd person to request support for fractional seconds. So I don't see it as being 'severly limiting'. I do understand your point of view of course... it's always frustrating when a module you want to use almost... but not quite... does what you need it to do. This has been the motivation for me writing a number of the modules I've created. In any case, I think a few simple wrapper routines would suffice to make use of Date::Manip and still get the precision you want. I'll investigate making Date::Manip a bit more fractional-second friendly... but I don't promise you the full support you are probably hoping for, and it's unfortunately not high on my priority list (right now I'm trying to get in better support for alternate character sets, and that's taking up most of my time that I can devote to Date::Manip). Good luck.

Wed Sep 22 13:08:24 2010 sbeck [...] cpan.org - Status changed from 'open' to 'resolved'

Wed Sep 22 13:09:37 2010 quanah.gibsonmount [...] gmail.com - Correspondence added

On Wed Sep 22 13:08:23 2010, SBECK wrote: Show quoted text

> I'll investigate making Date::Manip a bit more fractional-second > friendly... but I don't promise you the full support you are probably > hoping for, and it's unfortunately not high on my priority list (right > now I'm trying to get in better support for alternate character sets, > and that's taking up most of my time that I can devote to Date::Manip). > > Good luck.

Thanks, I appreciate it. :)

Wed Sep 22 13:09:38 2010 The RT System itself - Status changed from 'resolved' to 'open'

Wed Sep 22 13:10:27 2010 sbeck [...] cpan.org - Status changed from 'open' to 'resolved'