On Mon, 15 Dec 2003 23:02:49 -0600 (CST), Dave Rolsky wrote > On Mon, 16 Dec 2003, Rick Measham wrote: > > > - The normalisation works for all the tests, but kick it in the shins; > > does it really work? > > You should handle leap seconds too, otherwise it could be subtly broken > when using non-floating datetimes. This isn't that hard.
Figured it wasn't that hard, but this has been sitting in my progress-box for over a month. I decided to get it ready for beta release. I'll get leap seconds in there before the next release. > > There's a lot in the PODumentation so sorry for the reading, however I > > figure it's important to understand the concepts involved. > > The docs say you support both "normalize" and "normalise", but the code > only looks for the latter. Oops! Will fix before next release > I don't see a good reason to set the pattern as part of the object. Why > not just do this: > > my $dur_formatter = DateTime::Format::Duration->new( base => $base, normalize = > 1 ); > > print $dur_formatter->format_duration( duration => $dur, pattern => '%C' ); Mainly to make it work like all other format/parser modules. Maybe I could have it work both ways? If a pattern is supplied in the format_duration call, then I use it. If not, use the one in the object. If there's none in the object, die. > Having to create a new object for every pattern is just annoying. Yup, but that's the way strptime works and it's the way everything else works at the moment. There was talk of a 'meta parser' that could 'parse_datetime(format=>httpd datetime => xxx', this would be a similar thing. > All the other DateTime modules divide accessors into setters and getters, > so you should probably have ->base and ->set_base (and others) to be > consistent. :( I don't like doing it that way, and once again, my other modules don't do it that way. However if I'm the only one not doing it, then I'd better re-release the other stuff using that. I'll put a deprecation warning in the next release when they use the accessor to set. > The example formats you use in the docs are a bit confusing since they > look so much like actual datetimes. If there's a less ambiguous example > format you could use, that'd be good. Good point, easy to fix. > In the section on "Mixed positivity", you could also note that sometimes 1 > day minus 2 hours is _not_ 22 hours, at least in local time. Also, that > section might better be called "Mixed Positive and Negative Duration > Components". More wordy, but I think it's clearer. Will do > Looks like good work. Thanks! Cheers! Rick
