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
