[m-rev.] calendar module proposal
pbone at csse.unimelb.edu.au
Thu Jan 29 16:42:15 AEDT 2009
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the reviews