[
Lists Home |
Date Index |
Thread Index
]
OK, this is getting interesting :)
If you use the formula
UTC = local time timezone offset,
then UTC can't be constant relative to real time (civil time i think it's
called). In fact, looking at http://www.cl.cam.ac.uk/~mgk25/iso-time.html
UTC is just the newer name for GMT, so they are the same thing and hence if
GMT varies based on the time of year, so must UTC!? Let me rephrase;
although both GMT/UTC remain constant, all time relative to these (may) vary
and hence the meaning is pretty much completely lost (or at least can be out
of sync).
Unless I am missing something, using UTC in this manner is almost pointless
because resolution to some local time will
only make sense so long as you are in the correct time zone (interesting for
web services).
I can see this is addressed in 3.2.7.3 of
http://www.w3.org/TR/xmlschema-2/#dateTime, but it doesn't help me much.
"In general, the ·order-relation· on dateTime is a partial order since there
is no determinate relationship between certain instants."
My point is that although not determinate through a constant, they are
determinate via some other source (e.g.
http://www.twinsun.com/tz/tz-link.htm).
I don't expect XML Schema to validate this, but i would think it would be
useful to be able to indicate it. Kind of in the same way that the
"language" data type definition works.
My finishing example is I said to the directors of my imaginary global XML
company "We will meet every Monday at 2PM UTC". My point is that in the
summer this may mean 1PM and in the winter 2PM in some locale. Of course
it's easy for us to work out, but some application just receiving the data
has no way of co-ordinating these times into local times (which everyone
works in) because the time zone information is not indicated.
I understand that in a perfect world we would operate under the same time,
but we don't and hence scheduling is extermely difficult because you may end
up being an hour out from the intenteded time.
I am trying extremely hard to settle on this, but I then go back to my
scheduling application and realise that it will have problems when used in
co-ordinating activities accross multiple timezones. I have my own solution
which indicates the target timezone, but a discussion with people who know
timezone stuff better than me certainly helps !!
I understand convert all times to UTC and you'll be OK - but this really
only makes sense as long as these times remain in their originating
timezones when DST is applied.
Thanks,
A confused Steven
www.deltabis.com
----- Original Message -----
From: "Christopher R. Maden" <crism@maden.org>
To: <xml-dev@lists.xml.org>
Sent: Monday, December 24, 2001 2:04 AM
Subject: Re: [xml-dev] XML Schema and Timezones
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> At 20:44 23-12-2001, s.livingstone@btinternet.com 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.)
>
> ~Chris
> - --
> 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
>
> iQA/AwUBPCa3XaxS CWv7FjaEQJtpgCdGtqSqbAZyckpKduovzIe/QrD6c8AoN1H
> bY3LB1Mx AXwIlgbM2gHCkrh
> =ATkO
> -----END PGP SIGNATURE-----
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
|
