- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Mon, 24 Dec 2001 14:47:52 +0000
- To: s.livingstone@btinternet.com
- CC: xmlschema-dev@w3.org
Hi Steven, > I was originally using the XSD dateTime data type to determine the > date and time to perform a task, but this is limited when applied > globally, because the offset (timezone) is based on local time and > as soon as you replicate to some other timezone, the local time > changes and so your scheduling information goes nuts. I think that this idea of "local time" is what the version of dateTime *without* any timezone is supposed to support. So: 2002-07-16T14:00:00 means 2pm on July 16th, 2002, local time. In Britain this would be equivalent to 2002-07-16T14:00:00+01:00. In France, 2002-07-16T14:00:00+02:00 and so on. "Local time" could be resolved by the application, using whatever timezone information was available to it from the system. However, I would only use 'local time' if I was writing about repeating schedules (for example train times), where you could say "the train departs at 2pm every day", no matter whether it's summer or winter. If it's a one-off appointment, then I would use the exact time, with the timezone offset that was relevant at that particular time of the year, so Z during winter and +01:00 during summer (I think Scotland is the same as England here - winter is GMT and summer, BST, is +01:00). So since the appointment on 16th July is summer time, I'd use: 2002-07-16T14:00:00+01:00 But beware that according to the XML Schema Datatypes Recommendation, there's no distinction between 2002-07-16T14:00:00+01:00 and 2002-07-16T15:00:00Z - applications might justifiably lose the timezone information from the date value, so I wouldn't rely on it. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
Received on Monday, 24 December 2001 17:09:27 UTC