RFC: temporal data facilities of my DBMS language Muldis D

Hello,

As some of you may know, I've been developing a new language for defining 
and interacting with relational databases called Muldis D.  One can 
conceptualize this language as a generalization of the various SQL dialects 
that should be able to natively express any data value or operation in a 
rigorously defined and portable manner.  It can stand as an intermediate 
representation when translating SQL from one DBMS' flavor to another, or an 
intermediary between a DBMS and various DBMS wrappers such as ORMs etc. 
The language has 2 defined dialects, one being plain text like a normal 
language, and the other defined in terms of Perl data structures, arrays of 
arrays etc, which is a common input or internal format for ORMs these days. 
  The language design is more or less done, in that core features and how 
to bootstrap it are defined.  I'm currently working on an implementation, 
which should be runnable soon.

Tonight I just uploaded to CPAN version 0.48.0 of the spec, which you can 
now see at http://search.cpan.org/dist/Muldis-D/ .  The reason I am writing 
you is that this version includes the first rewrite of the temporal data 
types and operators that I am satisfied with, and I'm looking for your 
feedback towards their further improvement.  I am not seeking feedback 
about the language at large (though you can say anything you want), but 
specifically about the parts dealing with dates and times.

I prefer all responses to be on-list by default (assuming a datetime focus) 
unless you have a reason to reply in private instead.

Muldis D's datetime features are mainly inspired by both the SQL spec and 
by the DateTime module, and are defined closely to both, so they should be 
able to serve as a lossless intermediary between the Perl and database 
contexts.

There are 3 classes of data types, called UTCInstant, FloatInstant, and 
Duration (all 3 having YMDHIS components); the first 2 each have DateTime, 
Date, Time subtypes.  They are all defined in terms of integers, either 
directly or indirectly by way of rationals (seconds is rational); these are 
all arbitrary precision and radix independent, and can exactly represent 
values from base 10 or base 2 or base anything else; precision goes beyond 
nanosecond if needed.  The UTC and Float instants are identical in 
structure but are disjoint types, so they are not comparable, as is 
Duration with both.  (Muldis D is strongly typed and has explicit rules for 
what can be compared for equality and ordering, and the semantics when that 
is allowed.)

My language recognizes that there is no exact or constant conversion rate 
between many units (YM<->D<->HI<->S), so it stores them separately on 
purpose for best accuracy.  The feature set also supports incomplete 
datetimes, where one can just supply those of the 6 units they know as 
defined/Single values, and can leave the rest undefined/Nothing; undefined 
is treated as distinct from zero.  This incompleteness is also exploited 
such that the DateTime|Date|Time subtypes are simply defined as Instants 
where certain attributes are defined and others not; they are pre-defined 
names for the common cases of defined YMDHIS, YMD, HIS; all subtypes of the 
same root type are mutually comparable.  Leap days and seconds are 
supported, though only in regards to UTC/floating semantics.

For the moment, I decided for simplicity and for focus on the storage 
emphasis of databases, to not natively support multiple time zones nor 
daylight savings time offsets.  For a datetime you can choose either the 
fixed UTC time zone or a floating timezone.  If you want "local time" then 
you will have to convert to/from that externally (to the Muldis D 
intermediate representation, on the Perl side or DBMS side or both).  I 
think this is reasonable if you are just following the best practice of 
using UTC for storage and local only for display.  This all said, if an 
actual timezone offset carries useful information in a database, I can add 
support later for representing that, but it would be in the form of extra 
disjoint types that aren't comparable to the existing ones.

The specific parts of the Muldis D language spec dealing with date and time 
specific stuff can be seen at these 3 urls:

   http://search.cpan.org/dist/Muldis-D/lib/Muldis/D/Ext/Temporal.pod
   http://search.cpan.org/dist/Muldis-D/lib/Muldis/D/Dialect/PTMD_Tiny.pod
http://search.cpan.org/dist/Muldis-D/lib/Muldis/D/Dialect/HDMD_Perl_Tiny.pod

The Temporal.pod url has the actual datetime specific type and routine 
definitions.  You can think of one of those typedefs as being akin to an OO 
class definition and some subclass definitions; you can read the term 
"possrep" (possible representation) as being the fundamental object 
interface definition, each one typically providing the 6 type/object 
attributes YMDHIS.  The Temporal.pod doesn't list the selector/constructor 
routines (taking attr-name/value pairs) or attribute accessor routines, or 
generic comparator or sorting etc routines, that you expect, as those are 
defined elsewhere (Routines.pod, Ordered.pod) once for all/all-ordered 
language data types.  Note that all Muldis D values are immutable, so any 
mutators actually just return new values.  All type/object attributes are 
public though they are virtual so an implementation can do whatever it 
wants behind the scenes.  Each subtype adds a second possrep, so it is like 
each type has multiple object interfaces.  Users can also define their own 
subtypes/subclasses and add their own interfaces.

The only operators currently provided do addition/subtraction; in the 
future I anticipate fleshing these out to let users specify semantics more 
such as normalization and carry-over etc to take place in the operation, 
but for now I don't to keep it simple; I also anticipate adding 
multiply/divide and overlaps etc later, though the last will probably just 
be generic for all ordered types.

A portion each of the PTMD_Tiny.pod and HDMD_Perl_Tiny.pod files show the 
special literal syntax for value literals of datetime types provided by the 
existing Muldis D dialects, where you can define values as an ordered 
number list that is compact relative to the generic named form.

Anyway, details as I have them are at the above urls.  Let me know if you 
don't understand something and I will try to clarify.

Thanks in advance for any feedback or design etc help for my own datetime 
field contributions.

-- Darren Duncan