Re: [ESW Wiki] Update of "i18nFAQTimeZone" by RichardIshida

 >*[[RI* Please explain why this is called 'wall time'. It will help 
users, such as myself, who are not familiar with this term to recall 
it's meaning when you use it later in the document.]]

It is traditionally called "wall time", because that is what people see 
when they look at the clock on the wall (I didn't make this up).


 >*[[RI* This makes it sound like all time zones can vary. I think you 
should make it clearer that this is one case of a type of time zone 
where the relationship to UTC can vary. For example, for something like 
BST, such variation does not occur, and such time zones are only 
relevant for a part of a year.]]

A timezone ID in the sense discussed here encompasses not only an offset 
from GMT, but also rules for changing during a year. BST, on the other 
hand, is simply an alias for an offset, and not a timezone ID as 
described here. As such, it can be translated into a fixed offset from 
GMT (0). The timezone ID for where you live, on the other hand, is 
"Europe/London". Any given location on earth has a fixed timezone ID 
that covers all of the offsets and rules in place going back to 1970. It 
is fixed until such time as it changes either offset or rules from 
another location that shared that timezone ID. Thus right now San 
Francisco uses the "America/Los Angeles" TZID. If in the future San 
Francisco county were to change to a different set of rules or offset 
from LA, then a new TZID would be formed.

Clearly this needs more explanation.

 > *[[RI* I'm wondering how CLDR handles locations where there are 
multiple time zones due to daylight savings...]]

Two issues here. 1. CLDR only provides translated display names for 
timezone IDs. The IDs themselves are supplied by the TZ database. 2. 
There are no places with multiple timezones, since a timezone includes 
both offsets and rules, and covers history (back to 1970)


w3t-archive+esw-wiki@w3.org wrote:

>Dear Wiki user,
>
>You have subscribed to a wiki page or wiki category on "ESW Wiki" for change notification.
>
>The following page has been changed by RichardIshida:
>http://esw.w3.org/topic/i18nFAQTimeZone
>
>------------------------------------------------------------------------------
>  = Internationalization Core WG: Working with Times and Time Zones =
>  
>+ 
>+ 
>- This page is being used to build a W3C Note discussing the problem of date, time, and dateTime values with and without time zone offsets. When published, this note will be referred to from the XQuery 1.0 and XPath 2.0 Functions and Operators[8].  Examples are given mainly relying on XML Schema [6] and XQuery 1.0 and XPath 2.0 Functions and Operators [8], since these are the basis for XQuery and XSLT processing of date/time values.
>+ This page is being used to build a W3C Note discussing the problem of date, time, and dateTime values with and without time zone offsets. When published, this note will be referred to from the XQuery 1.0 and XPath 2.0 Functions and Operators[8]  '''[[RI''' specifications]].  Examples are given mainly relying '''[[RI''' that mainly rely]] on XML Schema [6] and XQuery 1.0 and XPath 2.0 Functions and Operators [8], since these are the basis for XQuery and XSLT processing of date/time values.
>  
>  ''by Addison Phillips, Felix Sasaki, Mark Davis, Martin Dürst''
>  
>@@ -25, +27 @@
>
>   * measuring the duration of an event
>   * comparing two time values
>  
>- '''Time Zone Independent Field-Based Time.''' The human representation of computer times is more complicated, and represents time using various separate field values, such as ''hour'', ''minute'', ''month'', or ''year''. One application for this type of representation is for values that are time zone independent, representing a logical event divorced from a particular location on the Earth. For example, a person's birth date is independent of time zone. Some other examples of this application of dates and times include:
>+ '''Time Zone Independent Field-Based Time.''' The human representation of computer times is more complicated, and represents time using various separate field values, such as ''hour'', ''minute'', ''month'', or ''year''. One application for this type of representation is for values that are time zone independent, representing a logical event divorced from a particular location on the Earth. '''[[RI''' At person's birth date (as opposed to birthday) is not obviously divorced from time zone considerations, esp. if you are trying to work out who is older.  You might make this clearer by saying something like "For example, recurring dates such as a person's birthday would normally fall into this category, partly because time is not expressed, and partly because the actual time of the start and end of the day for a given geographic location may not be considered important."]] For example, a person's birth date is independent of time zone. Some other examples of this application of dates and times '''[[RI''' note that the following examples only include dates, no times. Would be good to add something like regular meeting times, school day start and end times, etc.]] include:
>  
>-  * user's birth date
>+  * user's birth date '''[[RI''' this is not an 'other' example, since you just used it above]]
>   * employee hire date
>   * last day of the quarter
>   * holiday schedules
>@@ -45, +47 @@
>
>  
>  ''What is a "zone offset"?'' A "zone offset" is the difference in hours and minutes between a particular time zone and UTC. In ISO 8601, the particular ''zone offset'' can be indicated in a date or time value. The zone offset can be Z for UTC or it can be a value "+" or "-" from UTC. For example, the value {{{08:00-08:00}}} represents 8:00 AM in a time zone 8 hours behind UTC, which is the equivalent of {{{16:00Z}}} (8:00 ''plus'' eight hours). The value {{{08:00+08:00}}} represents the opposite increment, or midnight (08:00 ''minus'' eight hours).
>  
>- ''What is a "time zone"?'' A "time zone" is an identifier for a specific location or region which translates into a combination of rules for calculating the UTC offset. When an application (such as a website maintaining a group calendar) schedules a recurring meeting for ''08:00 Pacific Time'', it is referring to what is known as "wall time". This is '''not''' equivalent to either ''08:00-08:00'' or ''08:00-07:00'', because Pacific Time does not have a fixed offset from UTC; instead, the offset changes during the course of the year. As was mentioned before, XML Schema only supports zone offset, and it does not make the terminological distinction between zone offset and time zone. Note that the rules for computing when daylight savings takes effect may change from year to year, and from location to location.  Indiana, for example, does not follow daylight savings time but that will change in April 2006 [http://www.mccsc.edu/time.html].  The Northern and Southern hemispheres perform Daylight/Summer Time adjustments during opposing times during the year (corresponding to seasonal differences in the two hemispheres). 
>+ ''What is a "time zone"?'' A "time zone" is an identifier for a specific location or region which translates into a combination of rules for calculating the UTC offset. When an application (such as a website maintaining a group calendar) schedules a recurring meeting for ''08:00 Pacific Time'', it is referring to what is known as "wall time". '''[[RI''' Please explain why this is called 'wall time'.  It will help users, such as myself, who are not familiar with this term to recall it's meaning when you use it later in the document.]] This is '''not''' equivalent to either ''08:00-08:00'' or ''08:00-07:00'', because Pacific Time does not have a fixed offset from UTC; instead, the offset changes during the course of the year. '''[[RI''' This makes it sound like all time zones can vary. I think you should make it clearer that this is one case of a type of time zone where the relationship to UTC can vary.  For example, for something like BST, such variation does not occur, and such time zones are only relevant for a part of a year.]] As was mentioned before, XML Schema only supports zone offset, and it does not make the terminological distinction between zone offset and time zone. '''[[RI''' I think that the remainder of this paragraph should be in a separate para, perhaps with the title ''Rules for daylight savings'']] Note that the rules for computing when daylight savings takes effect may change from year to year, and from location to location.  Indiana, for example, does not follow daylight savings time but that will change in April 2006 [http://www.mccsc.edu/time.html].  The Northern and Southern hemispheres perform Daylight/Summer Time adjustments during opposing times during the year (corresponding to seasonal differences in the two hemispheres) '''[[RI''' and the changes go in different directions]]. 
>  
>  To capture these situations, a calendar system must use an ID for the time zone. The most definitive reference for dealing with wall time is the TZ database (aka ''Olson time zone database'', [http://www.twinsun.com/tz/tz-link.htm]), which is used by many systems such as UNIX, Linux, Java, CLDR, ICU, and many other systems and libraries. In the TZ database, ''Pacific Time'' is denoted with the ID {{{America/Los_Angeles}}}.  
>- The TZ database also supplies aliases among different IDs; for example, {{{Asia/Ulan Bator}}} is equivalent to {{{Asia/Ulaanbaatar}}}. From these alias relations, a canonical identifier can be derived. CLDR can be used to provide a localized form for the IDs: see Appendix J in [http://www.unicode.org/reports/tr35/].
>+ The TZ database also supplies aliases among different IDs; for example, {{{Asia/Ulan Bator}}} is equivalent to {{{Asia/Ulaanbaatar}}}. From these alias relations, a canonical identifier can be derived. CLDR can be used to provide a localized form for the IDs: see Appendix J in [http://www.unicode.org/reports/tr35/].  '''[[RI''' I'm wondering how CLDR handles locations where there are multiple time zones due to daylight savings...]]
>  
>  == Guidelines ==
>  
>  
>

Received on Friday, 7 October 2005 01:29:01 UTC