|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Schema and Timezones
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@m...> To: <xml-dev@l...> Sent: Monday, December 24, 2001 2:04 AM Subject: Re: XML Schema and Timezones > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > At 20:44 23-12-2001, s.livingstone@b... 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> >
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








