Lists Home |
Date Index |
-----BEGIN PGP SIGNED MESSAGE-----
At 20:44 23-12-2001, firstname.lastname@example.org wrote:
>Yes, but the actual time represented by the UTC time 14:00Z changes in the
>UK (for example) in winter relative to summer, as there is a 1 hour DST.
No - UTC never changes. The local time at Greenwich may change in the
summer, but UTC itself - the actual time - is invariant.
>So if you were to Schedule all calanders based on 14:00Z then this would
>imply a different schedule time in the summer (13:00 PM) in the UK than in
>the winter (14:00 PM)
A different *local* time, yes.
>There is no indicator of this and so your scheduling has the possiblity of
>being out an hour in different timezones.
No - given an absolute time (one in UTC or translatable to UTC because it
has a time zone indicated), a date, and a location, I can always figure out
local time. I need to know the time zone for that location on that date,
but then it's simple math.
>So, from your example,
>"2001-12-23T18:48-08:00 or 2001-12-24T04:48 02:00, both of which are
>equivalent to 2001-12-24T02:48Z."
>This is ok in the States (as it seems to hgave a constant differetial
>between the standard time and UTC), but other zones also change yearly for DST.
Most states of the US change for Daylight Savings Time.
>Hence, although 2001-12-23T18:48-08:00 or 2001-12-24T04:48 02:00, both of
>which are equivalent to 2001-12-24T02:48Z may be true in the summer, in
>the winter the second timezone (including 1 hour DST) could well be
>2001-12-24T04:48 01:00 and so an hour is lost (due to DST).
No. 04:48+02:00 is never equal to 04:48+01:00. It will only ever be equal
to 03:48+01:00 and 02:48Z. If local time offset is +02:00, then the time
is 04:48. If the local time offset is +01:00, then the time is
03:48. You're right that you do need to keep track of the offset from the
calendar, but that would be true even if you were only keeping local
time. (You can do that by omitting the time zone altogether - just 04:48 -
but then you've made the problem worse because you can't compare two times
since you don't know how they actually relate to each other.)
Christopher R. Maden, Principal Consultant, HMM Consulting Int'l, Inc.
DTDs/schemas - conversion - ebooks - publishing - Web - B2B - training
<URL: http://www.hmmci.com/ > <URL: http://crism.maden.org/consulting/ >
PGP Fingerprint: BBA6 4085 DED0 E176 D6D4 5DFC AC52 F825 AFEC 58DA
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.8
-----END PGP SIGNATURE-----