Indiana gains a business from Ohio due to adoption of DST
A press release today from the Dearborn County Economic Initiative claims that 3S Inc.'s recent move from Ohio to Dearborn County, Indiana was made possible by Indiana's recent adoption of daylight saving time. The press release quotes Matthew Euson, General Manager of 3S and a key decision maker with the relocation project, as saying: In addition to these factors, the change Indiana made to day light savings time also made the move to Indiana possible since most of our customers and vendors operate in this time zone. Reference: <http://www.insideindianabusiness.com/newsitem.asp?ID=19402> (2006-08-28 10:56:58 local time)
Hello everyone, Can someone please help me to understand how the zone rules are applied? For example, Europe/London first line states that it should be applied until 1847 Dec 1 0:00s. The second line should be applied until 1968 Oct 27 and defines GB-Eire as the rule set to use. However GB-Eire starts with a 1916 rule, leaving anything from 1847 until 1916 seemingly undefined. Thank you for your help. Srdjan ---- http://members.lycos.co.uk/phptz/
"Srdjan Krajnalic" <ludiskr@yahoo.com> writes:
However GB-Eire starts with a 1916 rule, leaving anything from 1847 until 1916 seemingly undefined.
Until the first rule applies, you use the first-listed rule that is on standard time (in this case, "GMT" with UTC offset zero). Unfortunately I don't see this point being covered clearly in the zic man page.
Hi Paul, Thank you for the clarification. Here is a related question/suggestion: For example, when blindly processing Rule Ghana 1936 1942 - Sep 1 0:00 0:20 GHST Rule Ghana 1936 1942 - Dec 31 0:00 0 GMT # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Accra -0:00:52 - LMT 1918 0:00 Ghana %s One is to apply LMT until 1918, then apply standard time zone offset until the first rule. However, one does not know what time zone name to apply for the given location, the best one can do is use GMT+/- based on the offset. Is it possible for you to easily add the default time zone name to the zone.tab file (provided zic does not display GMT offset)? Ff there is a way to an elegant solution please let me know :-) Thank you in advance, Srdjan -----Original Message----- From: Paul Eggert [mailto:eggert@CS.UCLA.EDU] Sent: Saturday, September 02, 2006 11:11 PM To: tz@lecserver.nci.nih.gov Subject: Re: Europe/London "Srdjan Krajnalic" <ludiskr@yahoo.com> writes:
However GB-Eire starts with a 1916 rule, leaving anything from 1847 until 1916 seemingly undefined.
Until the first rule applies, you use the first-listed rule that is on standard time (in this case, "GMT" with UTC offset zero). Unfortunately I don't see this point being covered clearly in the zic man page.
On Mon, Sep 04, 2006 at 10:12:54PM +0200, Srdjan Krajnalic wrote:
Here is a related question/suggestion:
For example, when blindly processing
Rule Ghana 1936 1942 - Sep 1 0:00 0:20 GHST Rule Ghana 1936 1942 - Dec 31 0:00 0 GMT # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Accra -0:00:52 - LMT 1918 0:00 Ghana %s
One is to apply LMT until 1918, then apply standard time zone offset until the first rule. However, one does not know what time zone name to apply for the given location, the best one can do is use GMT+/- based on the offset.
This is the same as Paul's other answer: from the end of LMT until the beginning of the Ghana rule (1936) (and again after 1942), the "standard time" (zero savings-time offet) part of the Ghana rule is to be used, and thus the abbreviation, according to the current rules, would be "GMT", and the GMT/UTC offset would be 0:00 . And again, clarification of this in the zic manpage appears to be needed... --Ken Pizzini
Hi Ken, Thank you for answering. That solution crossed my mind, but not being thoroughly familiar with data I thought better to ask because the time zone that appears to be appropriate is from the second rule line for the same year, but in same cases there is only one rule to apply to the given year. This one line still might provide the appropriate name, but again, without knowing the data real well... Also, having a variable number of zone lines per year makes it easier to make a mistake. So, if the only cases are "one or more lines, if two or more go with the second name" that's good enough :-) You are most likely right, the present rule line LETTERS should be the right answer in case of all one-line-per-year rules, whether they appear as the first line, in the middle, or as the last (or only) line. Another thing that might be worth mentioning - the problem from the previous letter may also occur in the middle of zone rules. For example: Rule Algeria 1918 only - Mar 9 23:00s 1:00 S Rule Algeria 1919 only - Mar 1 23:00s 1:00 S Rule Algeria 1920 only - Feb 14 23:00s 1:00 S Rule Algeria 1920 only - Oct 23 23:00s 0 - Rule Algeria 1921 only - Mar 14 23:00s 1:00 S Rule Algeria 1921 only - Jun 21 23:00s 0 - Rule Algeria 1939 only - Sep 11 23:00s 1:00 S Rule Algeria 1939 only - Nov 19 1:00 0 - In this case, between 1921-Jun-21 and 1939-Sep-11, the need again arises to resort to the default zone line GMTOFF. In case of Algiers, the last 1921 SAVE is appropriate through 1939-Sep-11 (0 SAVE in GMT), but in other cases it would not be. Regards, Srdjan -----Original Message----- From: Ken Pizzini [mailto:"tz."@explicate.org] Sent: Tuesday, September 05, 2006 12:58 AM To: Srdjan Krajnalic Cc: tz@elsie.nci.nih.gov Subject: Re: Default time zone for a location (previously Europe/London) On Mon, Sep 04, 2006 at 10:12:54PM +0200, Srdjan Krajnalic wrote:
Here is a related question/suggestion:
For example, when blindly processing
Rule Ghana 1936 1942 - Sep 1 0:00 0:20 GHST Rule Ghana 1936 1942 - Dec 31 0:00 0 GMT # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Accra -0:00:52 - LMT 1918 0:00 Ghana %s
One is to apply LMT until 1918, then apply standard time zone offset until the first rule. However, one does not know what time zone name to apply for the given location, the best one can do is use GMT+/- based on the offset.
This is the same as Paul's other answer: from the end of LMT until the beginning of the Ghana rule (1936) (and again after 1942), the "standard time" (zero savings-time offet) part of the Ghana rule is to be used, and thus the abbreviation, according to the current rules, would be "GMT", and the GMT/UTC offset would be 0:00 . And again, clarification of this in the zic manpage appears to be needed... --Ken Pizzini
On Tue, Sep 05, 2006 at 07:47:23AM +0200, Srdjan Krajnalic wrote:
Thank you for answering. That solution crossed my mind, but not being thoroughly familiar with data I thought better to ask
Sure...
because the time zone that appears to be appropriate is from the second rule line for the same year, but in same cases there is only one rule to apply to the given year.
I think we're still not explaining it right...
So, if the only cases are "one or more lines, if two or more go with the second name" that's good enough :-)
The choice is not not betwen first- and second- listed: the one to choose is whichever is the oldest entry (by "From" year) for standard time. And by "for standard time", I mean that the "SAVE" column is zero.
Another thing that might be worth mentioning - the problem from the previous letter may also occur in the middle of zone rules. For example:
Rule Algeria 1918 only - Mar 9 23:00s 1:00 S Rule Algeria 1919 only - Mar 1 23:00s 1:00 S Rule Algeria 1920 only - Feb 14 23:00s 1:00 S Rule Algeria 1920 only - Oct 23 23:00s 0 - Rule Algeria 1921 only - Mar 14 23:00s 1:00 S Rule Algeria 1921 only - Jun 21 23:00s 0 - Rule Algeria 1939 only - Sep 11 23:00s 1:00 S Rule Algeria 1939 only - Nov 19 1:00 0 -
In this case, between 1921-Jun-21 and 1939-Sep-11, the need again arises to resort to the default zone line GMTOFF. In case of Algiers, the last 1921 SAVE is appropriate through 1939-Sep-11 (0 SAVE in GMT), but in other cases it would not be.
Uh... no magic --- the last transition left us there, and we have yet to see the next transition: i.e., once the transition from daylight saving to standard time happened in June of 1921, Algiers continued to stay on standard time until the next transition in September of 1939. The key is that the Rule entries do not directly specify what the offset is for a given date, but rather they express the set of when transitions between standard and daylight saving time occur. The offset from UTC (nee GMT) is determined by the algebraic sum of the GMTOFF specified in the current Zone rule and the SAVE value specified in the most-recently-invoked Rule entry. The name assigned to the zone is determined by the FORMAT entry of the current Zone rule, possibly modified by the LETTER/S entry of the most-recently-invoked Rule entry. Put another way, the Zone and Rule entries are intended as a more compact and more readily edited way of expressing *transitions* within a time zone. Omitting the GMT/UTC offsets, this is what the entry for Algiers might look like written out in "longhand": Fri 1911-03-10 23:59:59 PMT -> 23:50:39 WET Wed 1916-06-14 22:59:59 WET -> 06-15 00:00:00 WEST Sun 1916-10-01 23:59:59 WEST -> 23:00:00 WET Sat 1917-03-24 22:59:59 WET -> 03-25 00:00:00 WEST Sun 1917-10-07 23:59:59 WEST -> 23:00:00 WET Sat 1918-03-09 22:59:59 WET -> 03-10 00:00:00 WEST Sun 1918-10-06 23:59:59 WEST -> 23:00:00 WET Sat 1919-03-01 22:59:59 WET -> 03-02 00:00:00 WEST Sun 1919-10-05 23:59:59 WEST -> 23:00:00 WET Sat 1920-02-14 22:59:59 WET -> 02-15 00:00:00 WEST Sat 1920-10-23 23:59:59 WEST -> 23:00:00 WET Mon 1921-03-14 22:59:59 WET -> 03-15 00:00:00 WEST Tue 1921-06-21 23:59:59 WEST -> 23:00:00 WET Mon 1939-09-11 22:59:59 WET -> 09-12 00:00:00 WEST Sun 1939-11-19 00:59:59 WEST -> 00:00:00 WET Sun 1940-02-25 01:59:59 WET -> 03:00:00 CET Mon 1944-04-03 01:59:59 CET -> 03:00:00 CEST Sun 1944-10-08 01:59:59 CEST -> 01:00:00 CET Mon 1945-04-02 01:59:59 CET -> 03:00:00 CEST Sun 1945-09-16 00:59:59 CEST -> 00:00:00 CET Sun 1946-10-06 23:59:59 CET -> 23:00:00 WET Sat 1956-01-28 23:59:59 WET -> 01-29 01:00:00 CET Sat 1963-04-13 23:59:59 CET -> 23:00:00 WET Sun 1971-04-25 22:59:59 WET -> 04-26 00:00:00 WEST Sun 1971-09-26 23:59:59 WEST -> 23:00:00 WET Thu 1977-05-05 23:59:59 WET -> 05-06 01:00:00 WEST Thu 1977-10-20 23:59:59 WEST -> 10-21 00:00:00 CET Fri 1978-03-24 00:59:59 CET -> 02:00:00 CEST Fri 1978-09-22 02:59:59 CEST -> 02:00:00 CET Thu 1979-10-25 23:59:59 CET -> 23:00:00 WET Thu 1980-04-24 23:59:59 WET -> 04-25 01:00:00 WEST Fri 1980-10-31 01:59:59 WEST -> 01:00:00 WET Thu 1981-04-30 23:59:59 WET -> 05-01 01:00:00 CET HTH, --Ken Pizzini
"Srdjan Krajnalic" <ludiskr@yahoo.com> writes:
For example, when blindly processing
Rule Ghana 1936 1942 - Sep 1 0:00 0:20 GHST Rule Ghana 1936 1942 - Dec 31 0:00 0 GMT # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Accra -0:00:52 - LMT 1918 0:00 Ghana %s
One is to apply LMT until 1918, then apply standard time zone offset until the first rule. However, one does not know what time zone name to apply for the given location,
If you're using standard time, the Rule line says the time zone name is "GMT" here, so that's what you'd use.
Is it possible for you to easily add the default time zone name to the zone.tab file
I'd rather not, since that would be one more thing to maintain by hand. I guess by "default time zone name" you mean the name of standard time in the foreseeable future, but that is something you should be able to compute from the existing data.
In the 64-bit versions of the time zone data files, all files end with a line of text that's either blank (rarely) or is a POSIX-style time-zone specifier for future times; judicious use of "tail -1" and "sed" in a shell script can produce a list of time zone abbreviations. --ado
"Olson, Arthur David \(NIH/NCI\) [E]" <olsona@dc37a.nci.nih.gov> writes:
In the 64-bit versions of the time zone data files, all files end with a line of text that's either blank (rarely) or is a POSIX-style time-zone specifier for future times; judicious use of "tail -1" and "sed" in a shell script can produce a list of time zone abbreviations.
It's not a text file, right? So "tail -1" is a bit dubious, as POSIX 1003.1-2004 <http://www.opengroup.org/susv3/utilities/tail.html> says that the input to "tail" must be a text file unless -c is specified. Also, this is more controversial, but POSIX says portable scripts are supposed to use "tail -n 1" rather than "tail -1". There are a few implementations that don't support the obsolete "tail -1" form.
Hello again everyone, apologies for the increase in traffic over the past few days. Please, can you confirm that under the new convention the only names not containing a / in the zone NAME are auxiliary zones such as PST8PDT, WET, MST7MDT, MET, etc, and that no actual location is ever specified without specifying a region as well. Many thanks, Srdjan
"Srdjan Krajnalic" <ludiskr@yahoo.com> writes:
Please, can you confirm that under the new convention the only names not containing a / in the zone NAME are auxiliary zones such as PST8PDT, WET, MST7MDT, MET, etc
The Theory file talks about this. It says that names normally have the form AREA/LOCATION. Older names lack a "/", but the newer names all have at least one "/", and they're all based on a specific location.
The Theory file talks about this. It says that names normally have the
Older names lack a "/", but the newer names all have at least one "/", and
Hi Paul, form AREA/LOCATION. they're
all based on a specific location.
I'm not sure which is the theory file, I'm looking at contents of tzdata2006k.tar.gz. In theory though, all old names are specified in backward file, and can be omitted without loss? Srdjan
"Srdjan Krajnalic" <ludiskr@yahoo.com> writes:
I'm not sure which is the theory file, I'm looking at contents of tzdata2006k.tar.gz.
It's a file named "Theory" in tzcode2006k.tar.gz.
In theory though, all old names are specified in backward file, and can be omitted without loss?
Yes.
On Wed, Sep 06, 2006 at 08:59:46PM +0200, Srdjan Krajnalic wrote:
It's a file named "Theory" in tzcode2006k.tar.gz.
"Some people have adjusted their work schedules to fit Mars time."
Does this help productivity? ;-)
It does... for the JPL folk who are working with data streams from probes that are on the surface of Mars. (Their significant-others, however, are generally not happy with the arrangement.) --Ken Pizzini
From: Paul Eggert Subject: Re: Europe/London Or more appropriately: Subject: Re: Default time zone for a location (previously Europe/London)
"Srdjan Krajnalic" writes:
However GB-Eire starts with a 1916 rule, leaving anything from 1847 until 1916 seemingly undefined. Until the first rule applies, you use the first-listed rule that is on standard time (in this case, "GMT" with UTC offset zero). Unfortunately I don't see this point being covered clearly in the zic man page.
I believe a similar situation was mentioned by me on 2004-05-17. If a Zone line gives a DST Rule, but no valid Rule can be found, then what? Example Korea: The last Rule lines: Rule ROK 1987 1988 - May Sun>=8 0:00 1:00 D Rule ROK 1987 1988 - Oct Sun>=8 0:00 0 S Some Zone lines: Zone Asia/Seoul 8:27:52 - LMT 1890 ... 8:30 - KST 1968 Oct 9:00 ROK K%sT For periods starting 1989 there is no valid Rule. The answer given by 'ado' May 2004 was: <quote> Remember that the Rules tell when DST transitions happen; in the above case, the Rule that's valid is one that specifies the last transition before May 2004 [read: today], which is assumed to be in effect in perpetuity. Generally speaking, we want to have the last line of a Zone refer to a Rule line. This is particularly important in cases where a country has multiple time zones. If the country decides in the future to change the way DST is handled (for example, decides to start observing DST again), we can make things right by changing one Rule rather than by changing multiple Zones. </quote> Maybe this repeated information helps writing clarifications for the manual.
Hi Oscar,
Example Korea: The last Rule lines: Rule ROK 1987 1988 - May Sun>=8 0:00 1:00 D Rule ROK 1987 1988 - Oct Sun>=8 0:00 0 S Some Zone lines: Zone Asia/Seoul 8:27:52 - LMT 1890 ... 8:30 - KST 1968 Oct 9:00 ROK K%sT
I may be repeating what you said ado said :-), for the sake of clarity: After the beginning (0:00) of Sun>=8 in Oct of 1988, you should perpetually apply GMT+9:00 (defined in the zone line), the correct zone name starting with Sun>=8 being KST (Korean STANDARD time). In some cases it's easy, in others manageable with some iteration through the rules, and it might be more accurate than to rely on a default zone name defined elsewhere, as proposed. Thank you all again for your help, Srdjan P.S. May I piggy-back a question regarding persistence of some of the rules and a greater picture of areas vs. locations? For example, Zone Africa/Algiers 0:12:12 - LMT 1891 Mar 15 0:01 0:09:21 - PMT 1911 Mar 11 # Paris Mean Time Paris longitude is, according to one source, 002 E 20 and Algiers is 003 E 03. To a certain extent one is tempted to interpret PMT as LMT because it is (?) based on politics and not time zone conventions, so the question is was time in Annaba (some 10* East of Algiers) offset by 0:09:21 in 1900, or was it LMT?
On Tue, Sep 05, 2006 at 06:47:46PM +0200, Srdjan Krajnalic wrote:
May I piggy-back a question regarding persistence of some of the rules and a greater picture of areas vs. locations?
Zone Africa/Algiers 0:12:12 - LMT 1891 Mar 15 0:01 0:09:21 - PMT 1911 Mar 11 # Paris Mean Time
Paris longitude is, according to one source, 002 E 20 and Algiers is 003 E 03. To a certain extent one is tempted to interpret PMT as LMT because it is (?) based on politics and not time zone conventions, so the question is was time in Annaba (some 10* East of Algiers) offset by 0:09:21 in 1900, or was it LMT?
Well, time zone conventions are based on politics, so I'm not completely sure what distinction you meant to convey there, but... Until 1891-03-15, Annaba would be following its own LMT, about 40 minutes ahead of Algiers (if your 10 degree comment is correct; it looks more like 5 degrees to me, but I don't have a good map). Then it would join Algiers in following PMT, along with the rest of Algeria: as a French colony, they would be observing France's official time, as referenced through the center of the principal transit instrument in the official observatory in Paris. --Ken Pizzini
participants (5)
-
Ken Pizzini
-
Olson, Arthur David (NIH/NCI) [E]
-
Oscar van Vlijmen
-
Paul Eggert
-
Srdjan Krajnalic