RE: ACTION A-Redmond05-01: timezone health warning

Hello Don, others,

At 06:52 05/09/14, Don Chamberlin wrote:

>Ashok et al,
>Recommendation 2 still needs work. At present it reads as follows:
>
>"2. Do not apply any operations based on date or time types (such as 
>indexing) if it is not certain that all of the data has zone offset 
>information or if all of the data does not have zone offset information."
>
>The current wording specifies two conditions in which indexing should not 
>be done: (a) "if it is not certain that all of the data has zone offset 
>information", or (b) "if all of the data does not have zone offset information."
>
>I do not think that this is what you mean to say.

I don't, either. I think the "is not certain" was meant to apply to
both sides of the 'or', which would then mean what to seem to want
below (but see below).

>It is quite reasonable to index data under condition (b), in which all 
>the data does not have zone offset information.
>
>I think you mean to say the following:
>
>"2. Do not apply any operations based on date or time types (such as 
>indexing) to collections of data in which some data items have zone offset 
>information and other data items do not have zone offset information."

I think this is what the text wants to say, but I think I have
to disagree with it. I think it's reasonable to say:
"If you only have times with zone offsets attached, go ahead and
compare/index/whatever them."
However, I do not think it's straightforward to say:
"If you only have times without zone offsets attached, go ahead and
compare/index/whatever them."
The reason for this is that times without zone offsets may mean
any of many things, and we don't know which one. In some cases,
it can be okay to compare/index, in other cases, that would be
wrong. Examples:

a) all the times are from the same zone; that's why the zone
    offset was left out in the first place
    => indexing/comparison is okay
b) times are 'wall clock' at a specific location
    => indexing/comparison may be okay, except potentially for the
       one hour in spring when daylight saving time is introduced
       (note that in fall, when going back to regular, there is
        no problem, because there are no doubled times, it's just
        an hour that is skiped)
c) times are 'wall clock', but in different locations (e.g.
    times from a flight schedule, where locations are given
    separately)
    => indexing/comparison isn't going to produce the right results.

Regards,    Martin.

Received on Saturday, 17 September 2005 04:26:40 UTC