[m-rev.] calendar module proposal

[Ian MacLarty]

On Tue, Jan 27, 2009 at 5:01 PM, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> The best representation of duration I've ever seen is Postgreql's
> internal INTERVAL structure.  It represents durations in terms of just
> three values (the minimum possible number of values): months, days, and
> seconds, although it allows a user to use any unit to express the
> interval.
>
> I recommend taking a look at Postgresql's INTERVAL:
>
> http://www.postgresql.org/docs/8.3/interactive/datatype-datetime.html#AEN4976
>

I've had a look at this, and I think that for my module months and
seconds (and microseconds) would be sufficient.  The reason given by
the Postgresql implementors for having a day dimension is that a day
may contain 23 or 25 hours if there is a daylight savings adjustment.
My module doesn't take into account daylight savings changes when
computing durations or adding durations to dates, so 1 days is always
equivalent to 60*60*24 seconds.  If a user wants to get an accurate
duration between two dates that may be in different daylight savings
phases, or different time zones, then they should ensure that those
two dates are in UTC.

Do you have any issues with this approach?  If not I'll add a note
explaining this in the module.

BTW the reason the module doesn't handle daylight savings changes is
because it would require knowing the current locale as well as having
a table of when daylight savings should change and how they have
changed in the past, for each locale.  That table would also need to
be adjusted if daylight savings times changed in the future.

Ian.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------