Re: Date

At 12:03 01/07/05 -0400, Noah_Mendelsohn@lotus.com wrote:
>Jeff Rafter writes:
>
> >> does this mean that an optional Time Zone Qualifier
> >> should be added
>
>Not sure, but there is some background that may be of interest.  First,
>many readers fail to recognize that in XML Schema Datatypes, timezone
>indicators are in the lexical representations only.  Their status is
>similar to leading zeros, or exponential notations (1E+2)  vs.
>unnormalized floats (100.0); timezones are visible, but not considered to
>affect the value of the time or integer respectively.  The times
>themselves are all effectively converted to a fixed UTC form for
>comparison or other use as values.

This is more or less true, except that XML Schema allows data
both to have a timezone and to not have a timezone. The above
is true for all data that has a timezone. Data without a timezone,
although it can be in the same field, doesn't easily compare with
data that has a timezone. I strongly recommend that if you are
going to define a schema, you make sure you use either only
data with a timezone or only data without a timezone.


>I argued
>against this design for timezones in particular, as I think it violates
>least-astonishment for users, but there it is.

It's definitely astonishing to some people that 21:00 (9pm) in
timezone +9:00 (Japan,...) and 07:00 (7am) in timezone -5:00
(winter e.g. in Boston, summer e.g. in Chicago) are the same.
But it's nevertheless a very clear fact.


>Also, Lotus (my employer) has some experience building timezone-aware
>applications.   Turns out we have had bugs reported, in calendaring
>applications for example, that were caused by political rather than
>technical actions.   A user schedules a meeting at 3PM in GMT-6, but they
>really think they're scheduling it in Chicago.  Chicago changes its laws,
>and the calander rings the alarm too early or late...it is indeed GMT-6,
>but it's no longer 3PM in Chicago.  These are real bugs from real users.

Yes indeed. The problem is that there is a difference between
GMT-6 (an absolute timezone) and 'the timezone Chicago is in'
(a 'dynamic' time zone).


>Some people argued for making the timezone dependent on an online
>catalog...

I.e. introducing 'dynamic' timezones that would have needed some kind of
updating mechanism.


>I think many of us feel that has a variety of undesireable
>characteristics.  On the other hand, this should be taken as a warning
>that solving users' problems with timezones is not nearly as easy as it
>appears, and sometimes it is better to do less than to add complexity that
>doesn't solve the problem.

Yes. One thing is to get the politicians to stop messing around :-).
The other thing is to use local times (i.e. times without timezones)
and have a separate timezone field (with 'dynamic' time zones),
and then try to do the math in the application (which can do a better
job at knowing whether it can use an online catalog, or gets updated
once in a while,...).

Regards,   Martin.

Received on Saturday, 7 July 2001 02:14:58 UTC