On Mon, 13 Aug 2001, David Cantrell wrote:
> On Mon, Aug 13, 2001 at 09:02:38AM -0400, John Peacock wrote:
> > David Cantrell wrote:
> > > TZ does if you are dealing with April 22 in London and April 7 in NZ,
> > > for instance. Is that 14, 15 or 16 days?
> > Or, my US-centric worldview
> > excluded the possibility that daylight savings time could begin on
> > different dates in different locations. :~)
>
> If you're interested in the number of days (or rather, the number of
> approximately 24-hour periods) then DST really doesn't matter, as at the
> most you'll be off by two hours. But if timezones are involved, you could
> be off by up to a day (and it could be an off-by-one or off-by-minus-one
> error depending on which direction you're travelling) if dealing with
> places either side of the IDL.
> > I would suggest that all dates be normalized to UTC (noon was mentioned
> > in another posting as an appropriate time) prior to calculation, then
> > restored to local time for output.
>
> Yes. You then get time differences as well as date differences for free.
Precisely. This is how Date::ICal's going to be doing things
(probably), once we add timezone/DST friendliness. Basically,
whenever you ask for output, you ask for output in a particular
offset from UTC. It's assumed that you know, or can find out, the
offset of your location or any other location you're dealing with.
For us, we'll be using some iCalendar features that give us a
timezone database, rather than relying on the Unix Olsen database,
but that's an implementation detail. The timezone database we're
using gives information about when DST switches over in each
locality. (That's VTIMEZONE, if you want to read RFC 2445 for the
details, or I can explain further if people care.)
In practical terms, the timezone/DST output-conversion issue means
that you can't have your internals nicely separated into a date
component and a time component, because timezone adjustments can
change either component. This is annoying, but I can't see an
elegant way around it (yet). Suggestions welcome.
srl
--
Shane R. Landrum [EMAIL PROTECTED]
we generate our own light to compensate for the lack of light from above -AD
GPG public key: http://cs.smith.edu/~slandrum/srl_pgpkey.txt
