Front page | perl.datetime |
Postings from October 2008
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 DuncanThread Previous | Thread Next