Re: Time Zones and XML Schema date types

>Is this a case where the common usage should outweigh other concerns,
>especially when common usage includes an international standard?  It seems
>as though XML Schema could have avoided adding to the ISO spec in this gray
>area by simply allowing implementations to assume GMT-- though I am even a
>little fuzzy with how I think this would work.  Essentially, isn't it safe
>to presume (although the XML Schema spec prohibits it):
>
>1999-01-16 = 1999-01-16T00:00:00Z

Small comment: I don't remember ever having seen time zones with
seconds.


>Assuming that 1999-01-16 is the 16th of January 1999-- shouldn't it follow
>that the starting instant of the date *is* 00:00:00Z?  I suppose not, I am
>faltering back and forth between a day is 24 hours (roguhly) beginning in
>timezone X and a day begins when the international date line is crossed. I
>am sure all of this has been thought through already (probably for many
>years now).

I think there are several use cases:

1) You know the date, but you don't exactly care about it's definition
    by the minute. In that case, you use a non-timezoned date. For a large
    part of traditional business correspondence, for example, a date can
    be handled just as a date. In some cases, it may be possible to infer
    the timezone from additional info (many business docs are signed with
    place and date), but it may not be appropriate to transfer this
    information to the date because it's not part of common usage.

2) You want to express the exact 24h period of a date in a particular
    time zone. In that case, you use a timezoned date.

3) You want to express some other period of time. In that case, you
    should use a complex type with a start time and an end time.

You have to decide what to do, for each of your application cases.
In cases 1) and 2), you may have to restrict your type to make
sure it contains (or does not contain) a time zone.

Also, you have to make sure your applications do the right thing
when converting. This depends on the application, and may be
complex.

Regards,   Martin.

Received on Wednesday, 9 May 2001 02:27:47 UTC