- From: Dan Chiba <dan.chiba@oracle.com>
- Date: Tue, 24 Jun 2008 11:08:00 -0700
- To: "Phillips, Addison" <addison@amazon.com>
- CC: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, "www-i18n-comments@w3.org" <www-i18n-comments@w3.org>
Phillips, Addison wrote: >>> I'm not sure about "RFC 822 zone offset", that is >>> for my European eyes rather US-centric, and not what >>> I'd expect in a memo claiming to be about I18N. The >>> draft says: >>> >>> | Note that RFC 822 zone offsets are not complete >>> | time zone identifiers >>> >>> >> Yes I think this is an important note. Zone offsets are not very >> useful >> because it does not identify a time zone. I think this note implies >> using Olson ID is preferred. (for this reason I intentionally put >> it >> first, switching from the order in the draft). >> > > I think you draw too broad a conclusion here. I agree that zone offsets do not fully identify time zones [1]. However, you can't really say that "zone offsets are not very useful", because there are plenty of cases in which they are exceedingly useful, such as the many cases in which one only has an offset and not a full time zone. To deny a system that has only the offset the ability to specify it seems foolish, which is why I included that particular representation originally. > I do think zone offsets are useful in some cases and should be valid. I did not mean to deny a system that can only identify the offset. I meant generally full time zone is preferred to offset alone. (However in reality full time zone identification is often not achieved or supported - web client, calendar, XML schema and ISO 8601, to name a few.) Regards, -Dan > I agree with Frank that the references we used originally are stale. > > > >> Allowing "Z" would be >> also good, because normalizing datetime values to UTC is very often >> a good idea. >> > > +1 > > > Addison > > [1] http://www.w3.org/TR/2005/NOTE-timezone-20051013/ >
Received on Tuesday, 24 June 2008 18:09:18 UTC