[m-rev.] calendar module proposal

[Paul Bone]

On Thu, Jan 29, 2009 at 04:32:16PM +1100, Ian MacLarty wrote:
> 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.

This sounds perfectly fine.  That's probably how I would have
implemented it and certainly how I would expect to have to use such an
API.

Even if your data types store UTC time internally and optionally convert
to a particular timezone in their interfaces.

> 
> 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.

This can probably be achived by using zoneinfo.  The C library should
provide methods for giving these conversions if it is given the
timezones to convert to/from.

That said I wouldn't want to complicate the calendar module further by
having to implement this.  Perhaps a seperate tz module (or sub-module
of calendar) might provide functions to convert times between different
timezones in the future.  There is no need to implement this now.

Thanks.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20090129/efcee23f/attachment.sig>