Re: HTML Time Zone proposal

> This seems to me to undermine the original use case. 


I see how you arrive at that conclusion, but I disagree because we see this problem ONLY when we combine an offset and a timezone, so we aren’t undermining anything if only tz is used or if only an offset is used:

* If we don’t use tz, we know what it means (some time defined with respect to UTC).

* 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).

My guess is that a case that combines tz and an offset will be the minority case, and we can specifically state that if a scenario needs to refer to a timezone, then tz should be used *with no offsets indicated* in the time string.

The problem is what to do with combinations that have a positive conflict (e.g., UTC+1215 but tz=“Americas/Phoenix”).

If we say that tz overrides the offset and the tz and the offset conflict, we have a real potential for unintended results and we will break things for some users.

My assumption is that if someone or some process has bothered to put in an offset, we should assume it had good reason to do so.

And what do we do with historical data that has an offset of +1 but a timezone of “Americas/Chicago” added? What meaning should we infer here? It should be reasonably clear that nobody used an offset of +1 to indicate Chicago time, so this isn’t a case of someone trying to double-code a time zone, but what does it mean?

> The whole point of specifying "5:00 PM on 2020-04-01, New York time" is that we do not know what UTC instant corresponds to that time,

That is still true. But if we encounter a time expressed with an offset (and there are lots of those already out there), we do know what it corresponds to in UTC and it is an entirely valid proposition to refer to whatever time will correspond to 14:00 UTC+2 in New York City on 2124-10-25. We don’t know what exact local time that will be yet, but we can still refer to it in your scenario.

So all I am suggesting is, if we have an offset + a tz, we would be saying “take this time, which we know exactly because we have the offset, and render it in a different time zone.” If we don’t have an offset indicated, then use the tz with no conversion, exactly as indicated in the initial proposal.

> but we may be required for legal or customary reasons (consider appointments in the future) to specify just that.  If the tz attribute cannot be used to specify the meaning of a timestamp, it is useless for that purpose.

Maybe I missed something, but how does this change with what I propose? Maybe you are responding to Addison’s comments rather than mine?

He did say it was recommended to use UTC for timestamps, but he did not say it is required. Maybe I’m thinking too narrowly, but when Addison referred to timestamps, I understood him to mean retrospective indications of past events that mark the moment when they occurred. In those cases future uncertainty is not an issue, so I did not see a problem with recommending the use of UTC.

For other kinds of time events your point about not knowing the offsets in advance is absolutely true. So we now need to be clear what we are referring to in the case of timestamps, because the narrower reading I had does make a difference.



In any event, what is clear is that there are more consequences to consider than are initially apparent.

And if everyone disagrees with me and says that we should allow tz to override offsets (with the realization that it means that different user agents will no longer agree on the semantics of time strings that were formerly unambiguous, which is not a trivial problem), then the document needs to be clear about what is meant (it was not, or we wouldn’t be having this discussion).

Best,

Arle

Received on Friday, 15 August 2014 15:08:16 UTC