Re: An approach to xsd:dateTime

On 28 Jul 2008, at 19:45, Jie Bao wrote:

> On Mon, Jul 28, 2008 at 2:17 PM, Bijan Parsia  
> <> wrote:
>> On 28 Jul 2008, at 19:02, Jie Bao wrote:
>>> To explain a bit more for my objection to the proposal at the F2F3:
>>> "PROPOSAL: datetime literals with missing timezones are not in the
>>> syntax; tools MAY insert a timezone, but SHOULD produce a warning if
>>> they do so"
>>> The part I object is that missing timezone should be disallowed from
>>> the syntax. In many cases, a time zone is a default context, and as
>>> default contexts typically behave, it may be omitted from a
>>> description from this context. Tools may or may not be able to
>>> rediscover a missing zone.
>> Yes. That's part of the point. We can't guess reasoanble ones.
>>> The burden should not be on users to always
>>> provide such information.
>> Who else?
> Tools may help in two ways: if such information can be rediscovered,
> then add it. If there is no way to find it precisely, then give it a
> *reasonable* interpretation.

But that reasoanble interpretation should be under user control. If  
we are going to spec an interpretation I'd prefer missing time zone's  
meant UTC time.

>>> My proposal is that treating missing timezone as partially specified
>>> datetime value. For example, "July 28, 2008" may mean a datetime  
>>> value
>>> that is within a local time in the date of July 28, 2008 on any
>>> timezone on the earth. Its interpretation could be an interval of  
>>> all
>>> such values in UTC, i.e., July 28, 2008 0:00:00 GMT-12 to July 28
>>> 23:59:59 GMT+12.
>> [snip]
>> I think it would be surprising for users to find what, I'm sure,  
>> they think
>> of as a point get turned into an interval.
> "July 28, 2008" is an interval in any timezone anyway.

Not, as I understand it, in the datetime lexical space. These  
*always* resolves to a point.

>> A sensible tool could propose interpreting missing times zones in  
>> a number
>> of ways including UTC or intervals. I'd find it *really odd* if my  
>> tool
>> interpreted a missing time zone as an interval. I'd be shocked,  
>> actually.
>> The asymmetry with how we handle other missing bits (defaulting to  
>> a point)
>> would be striking. (Er...if that's we handle it.)
> If datetime is only partially specified, making it fully specified by
> guessing the missing part (e.g., adding UTC by default) may be even
> more harmful than admitting that it is missing.

And it may be more harmful the other way.

Hence, we should have tools handle this since they can know more  
about what the user wants by, y'know, asking them.

If the user doesn't want to supply a time zone, the tool can insert a  
data range.

> I'm not against to let tools to warn users about missing time zone, or
> suggest users to assume a default time zone. However, if all those
> efforts failed, we may still need a way to interpret the partially
> specified data.

But why not just as another tool choice?


Received on Monday, 28 July 2008 18:49:08 UTC