From:	Darren Duncan	Date:	Wed Oct  1 17:42:09 2008
Subject:	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