RE: Draft for review: Working with Time Zones

Hi, as of now I've read all but the Guidelines of the draft,
http://www.w3.org/International/wiki/WorkingWithTimeZones
 
I do have a question for the section "Identifying Zone from Offset and Country."
 
How many time zones are in Russia?  It is not on the list of countries with more than one time zone (maybe there is something I do not understand).
 
My comments are below.

* * * COMMENTS * * *
What About Daylight Saving (Summer) Time: UTC Offset  (2nd par 1rst bullet)
 
"In addition, some time zones fall outside a single 24-hour span. "
 
{ How do they?  I'm a bit confused.  No need to clarify this but I guessed that
you meant for example that if we went from Greenwich back to Greenwich there could be more than 24 hours traversed -- because of daylight saving time or something? I guess I would like an example. }

* * *
What About Daylight Saving (Summer) Time: Daylight Savings / Summer Time  (2nd bullet)

"Since "spring" and "autumn" happen in opposite parts of the year in the northern and southern hemispheres. So regions in northern latitudes that share a base UTC offset with a region in a southern latitude will typically have very different DST rules."
 
{  COMMENT:  the sentence beginning with "Since" is a fragment; a clause with "Since" needs an indepedent clause to go with it.
However, with "So" beginning the next clause, you can omit "Since" here -- and perhaps change "So" to "Thus."
Alternately, you can join these two clauses, leaving the first with "Since", and omit "So" in the second }

=> "Spring" and "autumn" happen in opposite parts of the year in the northern and southern hemispheres.  [Thus] regions in northern latitudes that share a base UTC offset with a region in a southern latitude will typically have very different DST rules."
 
or ? =>  
"Since "spring" and "autumn" happen in opposite parts of the year in the northern and southern hemispheres, regions in northern latitudes that share a base UTC offset with a region in a southern latitude will typically have very different DST rules."
* * *
 
[ NOT IMPORTANT
Incremental Time, par 2, second sentence
 
"It represents the number of milliseconds since 00:00 (midnight) on January 1, 1970 in UTC (less all of the intervening leap seconds)."
{ COMMENT, you might add a note -- "see below" -- after leap seconds
}

=>
"It represents the number of milliseconds since 00:00 (midnight) on January 1, 1970 in UTC (less all of the intervening leap seconds [see below])."
]

* * *
 
[ NOT IMPORTANT? Floating Time, last par
 
{ COMMENT:  This may be a stupid question, but I did not understand the following: I think the day should only go to GMT-12:00?  For a twenty-four hour clock I mean. }
"That "day" can begin as early as midnight GMT-14:00 and end as late as midnight of January 2 GMT+12:00, depending on local time. This covers an incremental time range of fifty hours. "
}
]
* * *
Timestamps, 1rst par, 2nd sentence

"If your application can accurately generate incremental and/or field-based times based on UTC and the events are not tied to specific local time, all that is needed is the timestamp value itself. 
That is, if your application never needs to recover what the actual wall time was when event occurred and only cares about relative ordering of events. 
For example, if you merge log files from many machines together or if you are recording events in a log, a timestamp is perfectly adequate. For these types of time events, an incremental time or a field based time with an offset is all that is needed."
 
{ COMMENT:  insert "an" }
=>  "That is, if your application never needs to recover what the actual wall time was when an event occurred and only cares about relative ordering of events."
 
* * * 
Example, 2nd par

"If your application needed to represent a future recurring event, such as the time of a regular teleconference, an xs:dateTime value such as "2010-07-10T07:00:00-07:00" with an associated xs:duration field of "P7D" (i.e. weekly) would not tell you if the meeting should occur at a different actual wall time following the next daylight saving transition, and, if so, which time zone's rules should be applied in order to determine the changes. If the value "-07:00" is supposed to represent the U.S. Pacific time zone, then reminder messages might be generated for the wrong time once U.S. Pacific time transitions to standard time in the fall. In addition, users in other time zones, where the DST transition occurs on a different date, may find themselves unsure of when to call in to such a meeting. "
 
{ COMMENT:  For clarity, I would have liked a clarification that the Pacific Time Zone is on daylight time on the summer; just one additional phrase would fix it:
"on daylight time in July;"
also in the last sentence "into" is one word  }
=>
"If your application needed to represent a future recurring event, such as the time of a regular teleconference, an xs:dateTime value such as "2010-07-10T07:00:00-07:00" with an associated xs:duration field of "P7D" (i.e. weekly) would not tell you if the meeting should occur at a different actual wall time following the next daylight saving transition, and, if so, which time zone's rules should be applied in order to determine the changes. If the value "-07:00" is supposed to represent the U.S. Pacific time zone, then reminder messages might be generated for the wrong time once U.S. Pacific time, on daylight time in July, transitions to standard time in the fall. In addition, users in other time zones, where the DST transition occurs on a different date, may find themselves unsure of when to call into such a meeting. "
* * *
 
Example, 3rd (last) par
 
"Note that, although ISO 8601 is expressed in terms of the Gregorian calendar, it can be used to represent values in any calendar system. The presentation of date and time values to end users using different calendar and timekeeping systems is separate from the lexical representation, as the time value can be converted to an incremental time and then new field values computed for some other calendar or time keeping system that uses alternate rules. "
 
{ COMMENT: again you've got to decide between "timekeeping" and "time keeping" } 

* * *
Identifying Zone from Offset and Country, par 1

" Only twenty countries have more than one observed time zone. These countries are: 
Argentina, Australia, Brazil, Canada, Chile, Democratic Republic of the Congo, Ecuador, France, Greenland, Indonesia, Kazakhstan, Kiribati, Mexico, Micronesia, Mongolia, New Zealand, Portugal, Russia, Spain, and the United States. "
 
{ COMMENT ON CONTENT:  I don't see Russia; am I mistaken and does it only have one time zone or is there an omission?
I pulled up Russian time quickly in Wikipedia: http://en.wikipedia.org/wiki/Time_in_Russia }
 
* * *
Identifying Zone from Offset and Country, last par
 
"Within each of the countries that observe multiple time zones, knowing the current offset and current time will usually allow you to determine the time zone accurately. An exception to this is the United States: there exist some regions, such as Arizona, whose time zone cannot be determined strictly from country and offset, although an inferred time zone will always work for current time applications (not future and past times). "

{ COMMENT: regarding clarity, the comment about Arizona is confusing -- I assume you are talking about the fact that it does not go on daylight time in the summers and thus it's time is one hour behind the rest of the Mountain Time Zone in the summer; that's all I can think that you mean.  The rest of the year its time works fine. }

Incremental Versus Field-Based Time, 1rst par, last two sentences
 
"Field based times must be normalized and their individual fields compared. Field based times can have certain kinds of logical operations performed on them (for example, rolling the month forward or back), while incremental time requires a logical transformation. "

{ COMMENT:  you omitted the hyphens on "field-based times" }
=>
"Field-based times must be normalized and their individual fields compared. Field-based times can have certain kinds of logical operations performed on them (for example, rolling the month forward or back), while incremental time requires a logical transformation."

* * *
Incremental Versus Field-Based Time, 3rd par
 
"The SQL data types 'date', 'time', and 'timestamp' are field based time values which are intended to be zone offset independent: they are actually, technically, floating time values! The data type 'timestamp with time zone' is the zone offset-dependent equivalent of 'timestamp' in SQL. Programming languages, by contrast, tend to use incremental time and convert to and from a localized textual representation on demand. Databases may use incremental time or either zone offset-dependent or independent field-based structures internally. For example, Oracle databases treat a 'timestamp' field as though it is in the local time of the database instance. This can have unusual effects on queries: a field based time value that represents a local time with daylight saving needs to identify the UTC offset and whether daylight saving is in effect or not in order to disambiguate the repeated time when transitioning from daylight saving time (DST) to standard time. For example, in the United States in 2009, any instant between 1 and 2 am on November 1st happens twice, once in DST and a second time in standard time. Field based types without a time zone field (such as an Oracle timestamp) cannot represent the repeated times unambiguously without supplemental information provided externally. "

{ COMMENT:  again you've omitted the hyphens on "field-based" when it is acting as an adjective }
=>
"The SQL data types 'date', 'time', and 'timestamp' are field-based time values which are intended to be zone offset independent: they are actually, technically, floating time values! The data type 'timestamp with time zone' is the zone offset-dependent equivalent of 'timestamp' in SQL. Programming languages, by contrast, tend to use incremental time and convert to and from a localized textual representation on demand. Databases may use incremental time or either zone offset-dependent or independent field-based structures internally. For example, Oracle databases treat a 'timestamp' field as though it is in the local time of the database instance. This can have unusual effects on queries: a field-based time value that represents a local time with daylight saving needs to identify the UTC offset and whether daylight saving is in effect or not in order to disambiguate the repeated time when transitioning from daylight saving time (DST) to standard time. For example, in the United States in 2009, any instant between 1 and 2 am on November 1st happens twice, once in DST and a second time in standard time. Field-based types without a time zone field (such as an Oracle timestamp) cannot represent the repeated times unambiguously without supplemental information provided externally. "


Best,
 
--C. E. Whitehead
cewcathar@hotmail.com 
 


From: cewcathar@hotmail.com
To: addison@lab126.com; mark@macchiato.com; duerst@it.aoyama.ac.jp
CC: cowan@mercury.ccil.org; ishida@w3.org; www-international@w3.org
Date: Wed, 16 Feb 2011 10:43:48 -0500
Subject: RE: Draft for review: Working with Time Zones




Hi, Addison, all;
Regarding the draft at:  
http://www.w3.org/International/wiki/WorkingWithTimeZones 
 
Sorry; I've not looked at it carefully except for the first few sections (I've read through the stuff on railroad time).  I'll try to look at the rest tonight.
 
For now:

First section, Working With Time Zones, par 2
"This document contains guidelines and best practices for working with time and time zones in applications and document formats. Using the use cases below, you can choose the right approach that ensures that geographically distributed applications that work with time work well. This document also aims to provide a basic understanding and vocabulary for talking about time, a source of confusion for many developers and content authors on the Web. "
 
{ COMMENT:  awkward; I prefer
 
=> "With the use cases below to guide you, you can choose the right approach and thus ensure that . . . }
* * *
{ COMMENT on sections below:  For consistency you must choose either  "time keeping systems" or "timekeeping systems?," but  "timekeeping" is one word in "Modern timekeeping" when it's a noun } 
Section:  Observed Time 
"Most time keeping systems are organized around observable events, typically celestial ones such as sunrise, sunset, longest and shortest day of the year, the sun and moon's apparent position against the background stars, and so forth. For convenience, these events are then sub-divided into arbitrary units that make time more measurable: hours in a day, for example, or weeks in a month. In many timekeeping systems, " 

{ COMMENT: as I said, use consistently "time-keeping systems" or "time keeping systems" or "timekeeping systems;"
most online examples seem to prefer "time keeping" when this is used as an adjective, i.e.,, when it's used to modify "software" or "systems," even when I type in "timekeeping:"
http://www.google.com/search?q=timekeeping+software&hl=en&biw=802&bih=311&source=lnms&ei=yOJbTfm0CY-btweRy72bCw&sa=X&oi=mode_link&ct=mode&cd=1&ved=0CCcQ_AUoAA#sclient=psy&hl=en&biw=802&bih=311&q=time+keeping+software&aq=0s&aqi=g-s1g2g-s1g-o1&aql=&oq=&pbx=1&fp=e637dc619dfb9af3

http://www.google.com/search?q=timekeeping+software&hl=en&biw=802&bih=311&source=lnms&ei=yOJbTfm0CY-btweRy72bCw&sa=X&oi=mode_link&ct=mode&cd=1&ved=0CCcQ_AUoAA
 

Section:  Incremental Time, pars 1 and 2
"mechanical timekeeping"
"Universal Coordinated Time (UTC) is the basis for modern timekeeping: among other things, it provides a common baseline for converting between incremental and observed time."
{ COMMENT:  Great! "timekeeping" is right! here "timekeeping" is a noun and I prefer it as one word and so does the internet:
http://www.google.com/search?q=timekeeping+software&hl=en&biw=802&bih=311&source=lnms&ei=yOJbTfm0CY-btweRy72bCw&sa=X&oi=mode_link&ct=mode&cd=1&ved=0CCcQ_AUoAA#sclient=psy&hl=en&biw=804&bih=311&q=modern+time+keeping+&aq=&aqi=&aql=&oq=&pbx=1&fp=e637dc619dfb9af3

http://www.google.com/search?q=timekeeping+software&hl=en&biw=802&bih=311&source=lnms&ei=yOJbTfm0CY-btweRy72bCw&sa=X&oi=mode_link&ct=mode&cd=1&ved=0CCcQ_AUoAA#sclient=psy&hl=en&biw=802&bih=311&q=modern+timekeeping+&aq=0v&aqi=g-v1g-o1&aql=&oq=&pbx=1&fp=e637dc619dfb9af3
Also, according to word reference,
http://www.wordreference.com/definition/timekeeper
"timekeeping," at least when a noun, is one word. } 
* * *
Section:  What Is a Time Zone?  par 3
"Time zones were originated in several countries by railroad operators. The importance of maintaining a schedule is that people in the various locations served by the railroad know when the train would arrive (and depart). Coordinating trains could be scheduled between stations (using a single line in alternating directions, for example), avoiding observational error, local customs, and other issues combined with a plethora of "local times" to make accurate train scheduling of this sort difficult. "

{ COMMENTS:  
1.  verb tense . . . the modals "would" and "could" and "should" are actually past tense forms of the modals "wil" "can" and "may" and thus these all SHOULD be used with the past or conditional tense --
for your information.  Thus you cannot use "know," as that's a present tense verb form.
2.  Also the sentence is a bit awkward; "the importance of maintaining a schedule" is a long noun phrase . . . try using either a verb phrase, to make the sentence more "action-oriented," or else use a very short prepositional phrase;
either sounds better in English; for example
=> "With a schedule, people in the various locations served by the railroad knew . . . " (prep phrase)
=> "It was important to maintain a schedule so that . . . " [ verb phrase with explanation] }
3.  Finally, in the second sentence, I don't know what you want to say when you say "avoiding observational error, local customs, and other issues combined with a plethora of "local times" to make accurate train scheduling of this sort difficult"
but that clause is wordy and awkward and you have already said what you needed to say.
(In any case with or without time zones local customs and economies not to mention the weather did make train scheduling in some places a bit strange  --
people would wander in past the train time knowing it was not due yet but this is irrelevant.)

Whatever you want to do with this last clause, make it a new sentence I think. }
=>
"Time zones were originated in several countries by railroad operators.  [It was important to maintain a schedule [so] that people in the various locations served by the railroad knew when the train would arrive (and depart). 
Coordinating trains could be scheduled between stations (using a single line in alternating directions, for example). 
 
{Then add} =>
"The adjustment for time zones helped make it less necessary to guess the train arrival/departure times and reduced errors caused by differences in observed local time."
OR? =>
"The plethora of scheduling issues included scheduling based on observed local time, local customs, and more, but the adjustment for time zones helped to reduce errors resulting from differences in observed local time." 

 
* * *
Section:  What is a Time Zone?  last par
"This is a value small enough that most people won't notice the difference between actual and observed time. "
{ COMMENT:  you suddenly shift verb tense here -- in the preceding phrase you've used the past tense; this is o.k.,
but I prefer "don't" to "won't" in this case. }
=>
"This is a value small enough that most people don't notice the difference between actual and observed time. "
 
Best,
 
--C. E. Whitehead
cewcathar@hotmail.com