Re: HTML Time Zone proposal

Hi John,

See my email I sent just as this came it. It outlines the logical cases at play here. Only one of them is problematic, and I think it addresses some of your questions. I'm answering only a few points in this (not because I don't want to respond, but because I have limited time at the moment and just used most of it on my last email):

> 
>> * If we use tz and no offset, we know what it means (the time as
>> defined by the time zone, which may refer to a future point where we
>> do not yet know the offset).
> 
> How can that be downward compatible?

That isn't downward compatible. That is true. But we know what it means going forward and we are adding new functionality that allows us to take previously floating times and give them more specificity. Admittedly this is not entirely ideal, but there is no theoretical or practical way to avoid the fact that a system that doesn't know tz will take a time string with no offset and assume it is local to some (unknown) tz. Since this case cannot be helped in any way, I'm not going to worry about it.

> 
>> The problem is what to do with combinations that have a positive
>> conflict (e.g., UTC+1215 but tz=“Americas/Phoenix”).
> 
> We cannot tell in the general case what is a conflict, because any part
> of the earth might change its offsets and DST rules at any time.  This
> one may seem improbable, but the Philippines changed from UTC-6 to UTC+8
> at the end of 1845 (hence the trick question "What happened in the
> Philippines on Dec. 31, 1845?" to which the answer is "Nothing, because
> the date did not exist").  Similarly, Kiribati switched from - to + time
> in 2005, and there have been other cases.  So we must assume that if
> both offset and tz are present, a conflict exists.

No, we don't have to assume that at all. We have to assume it only for future dates. I realize your primary concern is for future dates, but not all uses will refer to future dates. And those future dates will, at some point, become past dates, at which point we will still be faced with the task of deciding upon their interpretation if the conflict remains.

> But that is not the scenario.  If I say "Let's meet in exactly five
> years at 5:00 in Grand Central Station", then I am specifying a local
> time, not a universal time.  IOW, I am saying "Let us meet at whatever
> universal time corresponds to this local time", not "Let us meet at
> whatever local time corresponds to this universal time".

Then it would be inappropriate to have an offset that implies a determined correspondence to universal time. I think the lesson here—which I would think we could both agree upon—is that there needs to be a strong SHOULD NOT at work here: “Applications referring to a time as defined by a time zone in a tz attribute SHOULD NOT include an offset in the time string.” We don't want systems to generate data that is in conflict with itself, and for anything generated going forward that matches your scenario, using only tz would make sense.

However, my concern here is what to do with cases where the two conflict (however they arise). Again, there are applications that use offsets today. If we allow tz to coexist with offsets by overriding them and someone uses them in a way that conflicts, we will GUARANTEE that older processes (which may be around for many years!) will interpret those time strings in a fundamentally different way than newer processes, no matter what the intended usage scenario is.

If we decide that is OK, then we need to document it very clearly and be aware that our intentions and usage scenarios will not change that fact. And since we cannot know what the downstream uses of data will be, we will create situations of positive conflict that may lead to real unintended problems.

Best,

Arle

Received on Friday, 15 August 2014 15:51:24 UTC