where is the zic source file for TZ=US/Eastern?
Nicolas Duchastel
(i.e. source files from Arthur David Olson).
I was able to generate most of the information I needed; but not all.
For example, my system is set with TZ=US/Eastern; but if I look in
/usr/share/lib/zoneinfo, I can only find a binary file for US/Eastern.
That is to say that there is a text source file called 'northamerica'
and it doesn't have any US/Eastern type zone: all of the zones are
'America/New_York' or similar.
Anybody know where I can get the source file for US/Eastern and other
files which are only found as binaries in the /usr/share/lib/zoneinfo
dir?
BTW, why is there "America/New_York" and then "US/Eastern" ?
Thank you in advance,
Nicolas
Darren Dunham
> I have an application which uses the text source files used by zic
> (i.e. source files from Arthur David Olson).
> I was able to generate most of the information I needed; but not all.
> For example, my system is set with TZ=US/Eastern; but if I look in
> /usr/share/lib/zoneinfo, I can only find a binary file for US/Eastern.
> That is to say that there is a text source file called 'northamerica'
> and it doesn't have any US/Eastern type zone: all of the zones are
> 'America/New_York' or similar.
Right. I believe that since timezones were historically done by cities
and not necessarily regions, zone information is maintained by city
names. A region can be constructed by linking it to a particular city.
> Anybody know where I can get the source file for US/Eastern and other
> files which are only found as binaries in the /usr/share/lib/zoneinfo
> dir?
/usr/share/lib/zoneinfo/src/northamerica and
/usr/share/lib/zoneinfo/src/backward should be all the information you
need.
> BTW, why is there "America/New_York" and then "US/Eastern" ?
US/Eastern is just a link to America/New_York when you build it with
the two files in Solaris.
Solaris appears to ship only with the US/* files rather than the
America/* files.
--
Darren Dunham ddu...@taos.com
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
Paul Eggert
> why is there "America/New_York" and then "US/Eastern" ?
The old Olson tradition was to use names like "US/Eastern" and "ROC",
but those names didn't scale up well to a naming convention that would
both cover the planet and survive common political events like the
renaming of countries. The new naming convention uses names like
"America/New_York" to try to avoid those problems.
The old names are still supported for backward compatibility, though.
Chris Thompson
Darren Dunham <ddu...@redwood.taos.com> wrote:
[...]
>> BTW, why is there "America/New_York" and then "US/Eastern" ?
>
>US/Eastern is just a link to America/New_York when you build it with
>the two files in Solaris.
>
>Solaris appears to ship only with the US/* files rather than the
>America/* files.
Solaris 9 ships with all the zoneinfo files pre-compiled.
Chris Thompson
Email: cet1 [at] cam.ac.uk
Nicolas Duchastel
> In comp.unix.solaris Nicolas Duchastel <ducha...@telecomsys.com> wrote:
> > I have an application which uses the text source files used by zic
> > (i.e. source files from Arthur David Olson).
>
> > I was able to generate most of the information I needed; but not all.
>
> > For example, my system is set with TZ=US/Eastern; but if I look in
> > /usr/share/lib/zoneinfo, I can only find a binary file for US/Eastern.
>
> > That is to say that there is a text source file called 'northamerica'
> > and it doesn't have any US/Eastern type zone: all of the zones are
> > 'America/New_York' or similar.
>
> Right. I believe that since timezones were historically done by cities
> and not necessarily regions, zone information is maintained by city
> names. A region can be constructed by linking it to a particular city.
>
> > Anybody know where I can get the source file for US/Eastern and other
> > files which are only found as binaries in the /usr/share/lib/zoneinfo
> > dir?
>
> /usr/share/lib/zoneinfo/src/northamerica and
> /usr/share/lib/zoneinfo/src/backward should be all the information you
> need.
>
> > BTW, why is there "America/New_York" and then "US/Eastern" ?
>
> US/Eastern is just a link to America/New_York when you build it with
> the two files in Solaris.
yes and no: thanks for the info; but that doesn't give me what I need:
Where is the SOURCE text file for US/Eastern?
--> i.e. remember that what I am after is to be able to use the same
source file used by ZIC such that I can build some other stuff in my
application.
I do see that 'backward' creates a "link" from 'America/New_York' to
'US/Eastern' (or is it the opposite !?), but thats in the source text
file!
Thats not a file link (i.e. as in 'ln -s'). It's a line like:
Link America/New_York US/Eastern
e.g. if I set my TZ in /etc/default/init to America/New_York; how does
the system end-up with US/Eastern!? i.e.
does the system know internally about 'backward' !? sounds kind of
weird to have a filename like that hard-coded into the process !? but
then again....
>
> Solaris appears to ship only with the US/* files rather than the
> America/* files.
That's correct! I checked on a bunch of machines I have access to;
both on Solaris 7 and 8 (I have no Solaris 9 yet); and they all seem
the same:
a) data only files such as US/Eastern (and others under US);
b) source text file named 'northamerica';
c) no America directory
d) no America/New_York or New_York data file anywhere!?
The weird thing is that in source text file 'northamerica', it has an
heading somewhere which seems to say the opposite from what the text
source file 'backward' says:
---> which is the correct, newer timezone for east coast
north-america !?
a) America/New_York
b) EST5EDT
c) US/Eastern
d) ....
Chris Thompson
Nicolas Duchastel <ducha...@telecomsys.com> wrote:
[...]
>yes and no: thanks for the info; but that doesn't give me what I need:
>
>Where is the SOURCE text file for US/Eastern?
>--> i.e. remember that what I am after is to be able to use the same
>source file used by ZIC such that I can build some other stuff in my
>application.
>
>
>I do see that 'backward' creates a "link" from 'America/New_York' to
>'US/Eastern' (or is it the opposite !?), but thats in the source text
>file!
>Thats not a file link (i.e. as in 'ln -s'). It's a line like:
>
> Link America/New_York US/Eastern
When zic(1m) compiles that file, it creates the hard link. Try it!
>e.g. if I set my TZ in /etc/default/init to America/New_York; how does
>the system end-up with US/Eastern!? i.e.
It doesn't, unless init's TZ value gets over-ridden by /use/default/login
(nearly always a bad idea) or some other start-up file.
>does the system know internally about 'backward' !? sounds kind of
>weird to have a filename like that hard-coded into the process !? but
>then again....
The "system" (i.e. the libc.so routines) doesn't know about the
source files at all. It just uses the compiled versions under
/usr/share/lib/zoneinfo.
Prior to Solaris 9, Sun distributed only an historical subset
of the zoneinfo files pre-compiled. To get the same effect
from the source files you would need to zic(1m) everything,
which would leave /usr/share/lib/zoneinfo/America/New_York
and /usr/share/lib/zoneinfo/US/Eastern as hard links to the
same file, and then remove most of the "new" names like
America/New_York.
>> Solaris appears to ship only with the US/* files rather than the
>> America/* files.
>
>That's correct! I checked on a bunch of machines I have access to;
>both on Solaris 7 and 8 (I have no Solaris 9 yet); and they all seem
>the same:
>
>a) data only files such as US/Eastern (and others under US);
>b) source text file named 'northamerica';
>c) no America directory
>d) no America/New_York or New_York data file anywhere!?
>
>The weird thing is that in source text file 'northamerica', it has an
>heading somewhere which seems to say the opposite from what the text
>source file 'backward' says:
> ---> which is the correct, newer timezone for east coast
>north-america !?
> a) America/New_York
> b) EST5EDT
> c) US/Eastern
> d) ....
Anything is "correct" if it gives the desired effect, but note that
TZ=EST5EDT doesn't mean using the zoneinfo file, but the Posix rules
(see the _long_ description in the environ(5) man page). You can
force use of the zoneinfo file by TZ=:EST5EDT, but it wouldn't be
my prefered choice of name.
Carl Lowenstein
Nicolas Duchastel <ducha...@telecomsys.com> wrote:
>
>
>Where is the SOURCE text file for US/Eastern?
>--> i.e. remember that what I am after is to be able to use the same
>source file used by ZIC such that I can build some other stuff in my
>application.
Google is your friend. It took only one try to find
< http://www.twinsun.com/tz/tz-link.htm >
which is a page full of timezone information as well as links to
the real source code.
carl
--
carl lowenstein marine physical lab u.c. san diego
clow...@ucsd.edu
Darren Dunham
> yes and no: thanks for the info; but that doesn't give me what I need:
> Where is the SOURCE text file for US/Eastern?
America/New_York
> I do see that 'backward' creates a "link" from 'America/New_York' to
> 'US/Eastern' (or is it the opposite !?), but thats in the source text
> file!
> Thats not a file link (i.e. as in 'ln -s'). It's a line like:
> Link America/New_York US/Eastern
If you do
% zic -d /tmp/zones src/northamerica
% zic -d /tmp/zones src/backward
% ls -l /tmp/zones/US/Eastern /tmp/zones/America/New_York
-rw-r--r-- 3 ddunham admin 1250 May 5 16:44 /tmp/zones/America/New_York
-rw-r--r-- 3 ddunham admin 1250 May 5 16:44 /tmp/zones/US/Eastern
It is a real link. It is the same file.
Tony Walton
>
>
>
> yes and no: thanks for the info; but that doesn't give me what I need:
>
> Where is the SOURCE text file for US/Eastern?
There isn't one, _per se_. You answered your own question below.
>
>
> I do see that 'backward' creates a "link" from 'America/New_York' to
> 'US/Eastern' (or is it the opposite !?), but thats in the source text
> file!
> Thats not a file link (i.e. as in 'ln -s'). It's a line like:
>
> Link America/New_York US/Eastern
>
> e.g. if I set my TZ in /etc/default/init to America/New_York; how does
> the system end-up with US/Eastern!?
The Link keyword sets up the, er, link when zic processes a sourcefile.
See the zic(1M) manpage:
Link
A link line has the form:
Link LINK-FROM LINK-TO
For example:
Link Europe/Istanbul Asia/Istanbul
The LINK-FROM field should appear as the NAME field in some
zone line; the LINK-TO field is used as an alternate name
for that zone.
>
> does the system know internally about 'backward' !?
Yup.
> sounds kind of
> weird to have a filename like that hard-coded into the process !? but
> then again....
That's what it's called on elsie <ftp.elsie.nci.nih.gov> which is where
the timezone source comes from - as the name suggests, it's there for
backward compatibility between the more modern zone names (like
America/New_York or Europe/London) and the older names like US/Eastern
or GB.
>
>
>
>>Solaris appears to ship only with the US/* files rather than the
>>America/* files.
That's true up to and including Solaris 9. Subsequent to that a full
set is supplied.
>
>
> That's correct! I checked on a bunch of machines I have access to;
> both on Solaris 7 and 8 (I have no Solaris 9 yet);
Aha.
> and they all seem
> the same:
>
> a) data only files such as US/Eastern (and others under US);
> b) source text file named 'northamerica';
> c) no America directory
> d) no America/New_York or New_York data file anywhere!?
>
> The weird thing is that in source text file 'northamerica', it has an
> heading somewhere which seems to say the opposite from what the text
> source file 'backward' says:
> ---> which is the correct, newer timezone for east coast
> north-america !?
> a) America/New_York
That one.
> b) EST5EDT
That's also correct but is a completely different type of zone
specification (POSIX as opposed to Olson)
> c) US/Eastern
Old but still widely used.
--
Tony
Villy Kruse
Tony Walton <tony....@s-u-n.com> wrote:
>
>> b) EST5EDT
>
>That's also correct but is a completely different type of zone
>specification (POSIX as opposed to Olson)
>
>
>
The tables do, however, have entries for EST5EDT same as America/New_York
just in case the timezoue routines can't handle the posix TZ variables.
From the file northamerica
Link America/New_York EST5EDT
From the file systemv
Zone SystemV/EST5EDT -5:00 SystemV E%sT
An exampel of using full POSIX TZ variable:
$ TZ=MET-1MEST,M3.5.0,M10.5.0/3 date
Tue May 6 17:11:45 MEST 2003
And using Olson table:
$ date
Tue May 6 17:11:45 CEST 2003
Villy
Tony Walton
> On Tue, 06 May 2003 11:08:50 +0100,
> Tony Walton <tony....@s-u-n.com> wrote:
>
>
>
>>> b) EST5EDT
>>
>>That's also correct but is a completely different type of zone
>>specification (POSIX as opposed to Olson)
>>
>>
>>
>
>
> The tables do, however, have entries for EST5EDT same as America/New_York
> just in case the timezoue routines can't handle the posix TZ variables.
True, but I'm guessing that the OP is talking about Solaris (given that
2/3 of the groups this is posted to are Sun-specific). Solaris will
parse EST5EDT as a POSIX string (and will parse :EST5EDT - with leading
colon - as an Olson file of that name).
Specify a POSIX zone:
$ TZ=EST5EDT truss -t open date
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
open("/usr/lib/libc.so.1", O_RDONLY) = 3
open("/usr/lib/libdl.so.1", O_RDONLY) = 3
open("/usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1", O_RDONLY) = 3
open("/usr/lib/locale/en_GB.ISO8859-1/en_GB.ISO8859-1.so.2", O_RDONLY) = 3
Tuesday May 6 11:28:58 EDT 2003
Note that nothing in /usr/share/lib/zoneinfo was opened.
Specify an Olson zone:
$ TZ=GB truss -t open date
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
open("/usr/lib/libc.so.1", O_RDONLY) = 3
open("/usr/lib/libdl.so.1", O_RDONLY) = 3
open("/usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1", O_RDONLY) = 3
open("/usr/lib/locale/en_GB.ISO8859-1/en_GB.ISO8859-1.so.2", O_RDONLY) = 3
open("/usr/share/lib/zoneinfo/GB", O_RDONLY) = 3
Tuesday May 6 16:29:24 BST 2003
This time, /usr/share/lib/zoneinfo/GB was opened.
Specify a POSIX-y looking Olson zone but tell the system it really is Olson:
$ TZ=:EST5EDT truss -t open date
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
open("/usr/lib/libc.so.1", O_RDONLY) = 3
open("/usr/lib/libdl.so.1", O_RDONLY) = 3
open("/usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1", O_RDONLY) = 3
open("/usr/lib/locale/en_GB.ISO8859-1/en_GB.ISO8859-1.so.2", O_RDONLY) = 3
open("/usr/share/lib/zoneinfo/EST5EDT", O_RDONLY) = 3
Tuesday May 6 11:29:37 EDT 2003
--
Tony
Tony Walton
> Google is your friend. It took only one try to find
> < http://www.twinsun.com/tz/tz-link.htm >
> which is a page full of timezone information as well as links to
> the real source code.
Round of applause for Mr Eggert, please (that'd be Paul Eggert
<egg...@twinsun.com> ) who posted further up this thread.
Listen to Paul's words - he speaks truth.
--
Tony
Nicolas Duchastel
> In comp.unix.solaris Nicolas Duchastel <ducha...@telecomsys.com> wrote:
>
> > yes and no: thanks for the info; but that doesn't give me what I need:
>
> > Where is the SOURCE text file for US/Eastern?
>
> America/New_York
>
> > I do see that 'backward' creates a "link" from 'America/New_York' to
> > 'US/Eastern' (or is it the opposite !?), but thats in the source text
> > file!
> > Thats not a file link (i.e. as in 'ln -s'). It's a line like:
>
> > Link America/New_York US/Eastern
>
> If you do
>
> % zic -d /tmp/zones src/northamerica
> % zic -d /tmp/zones src/backward
> % ls -l /tmp/zones/US/Eastern /tmp/zones/America/New_York
>
> -rw-r--r-- 3 ddunham admin 1250 May 5 16:44 /tmp/zones/America/New_York
> -rw-r--r-- 3 ddunham admin 1250 May 5 16:44 /tmp/zones/US/Eastern
>
> It is a real link. It is the same file.
This is all very nice; but....original question was:
"were is the source for US/Eastern files?"
i.e. where is the TEXT source file from which I would create, using
zic, the file US/Eastern. It needs to be a text file which has a
'ZONE' with US/Eastern!....
i.e. I havent seen any Olson files which have that!
I am using Solaris 8; it includes a BINARY file for US/Eastern but no
text file for it!! It has a text SOURCE file which includes, among
others, America/New_York; and we all know that America/New_York and
US/Eastern are the same... BUT..... a script wont!
BTW, I know that if I were to build using zic and the source files
from Olson, I would get some BINARY file with US/Eastern from the
bunch of source text files; but... lets just image that I start from a
'regular' Solaris 8 installation: i.e. no zic compiled or anything!!!
i.e. my goal is to search for all text source files in
/usr/share/lib/zoneinfo and then parse each file looking for the last
RULE for any given ZONE; and presto, I can build some C++ program
which contains the same information I need (i.e.. dont worry about why
I am doing that; its designed that way :), please, just focus on the
question: is there a source file !?)
The BINARY is useless to me: i.e. its hard to parse :)
That said, I really appreciated all the help; and I learnt a lot.
Dave Uhring
> i.e. my goal is to search for all text source files in
> /usr/share/lib/zoneinfo and then parse each file looking for the last
> RULE for any given ZONE; and presto, I can build some C++ program
> which contains the same information I need (i.e.. dont worry about why
> I am doing that; its designed that way :), please, just focus on the
> question: is there a source file !?)
Try this source, the one for Solaris is available only with difficulty
and/or expense.
ftp://ftp1.freebsd.org/pub/FreeBSD/branches/4.0-stable/src/share/zoneinfo/
Chris Thompson
In article <2955052e.03050...@posting.google.com>,
Nicolas Duchastel <ducha...@telecomsys.com> wrote:
[...]
>This is all very nice; but....original question was:
>
>"were is the source for US/Eastern files?"
>
>i.e. where is the TEXT source file from which I would create, using
>zic, the file US/Eastern. It needs to be a text file which has a
>'ZONE' with US/Eastern!....
There _isn't_ a single text file. You need both of
/usr/share/lib/zoneinfo/src/northamerica
/usr/share/lib/zoneinfo/src/backward
and _together_ these specify many timezones, including US/Eastern.
>i.e. I havent seen any Olson files which have that!
That's because they don't exist.
>I am using Solaris 8; it includes a BINARY file for US/Eastern but no
>text file for it!! It has a text SOURCE file which includes, among
>others, America/New_York; and we all know that America/New_York and
>US/Eastern are the same... BUT..... a script wont!
A script can do whatever you are up to programming it to do.
If you want to emulate all the actions of zic(1m), then it
can be done, it you are masochistic enough.
>BTW, I know that if I were to build using zic and the source files
>from Olson, I would get some BINARY file with US/Eastern from the
>bunch of source text files; but... lets just image that I start from a
>'regular' Solaris 8 installation: i.e. no zic compiled or anything!!!
>
>i.e. my goal is to search for all text source files in
>/usr/share/lib/zoneinfo and then parse each file looking for the last
>RULE for any given ZONE; and presto, I can build some C++ program
>which contains the same information I need (i.e.. dont worry about why
>I am doing that; its designed that way :), please, just focus on the
>question: is there a source file !?)
>
>The BINARY is useless to me: i.e. its hard to parse :)
The compiled zoneinfo files are actually much easier to parse than
the zic input files, but of course they don't contain as much
information, only covering the period 13-Dec-1901 to 19-Jan-2038,
and not having any comments ...
>That said, I really appreciated all the help; and I learnt a lot.
You're welcome.
The "last rule" for a zone is, of course, often based on reading
tea leaves, as governments do like to keep tinkering with them.
Tony Walton
> Darren Dunham <ddu...@redwood.taos.com> wrote in message news:<6MCta.620$Ni4.10...@newssvr14.news.prodigy.com>...
>
>
> This is all very nice; but....original question was:
>
> "were is the source for US/Eastern files?"
>
> i.e. where is the TEXT source file from which I would create, using
> zic, the file US/Eastern. It needs to be a text file which has a
> 'ZONE' with US/Eastern!....
Regardless of what you may think you need, that file /does not exist/.
>
> i.e. I havent seen any Olson files which have that!
Because there aren't any. As I said in my posting (Message-ID:
<3EB789B...@s-u-n.com>) from two days ago:
> Nicolas Duchastel wrote:
>
>>
>>
>>
>> yes and no: thanks for the info; but that doesn't give me what I need:
>>
>> Where is the SOURCE text file for US/Eastern?
>
> There isn't one, _per se_.
Please re-read that posting and the others in this thread, most of which
say exactly the same thing but in different words.
Regards
--
Tony
Darren Dunham
>> > I do see that 'backward' creates a "link" from 'America/New_York' to
>> > 'US/Eastern' (or is it the opposite !?), but thats in the source text
>> > file!
>> > Thats not a file link (i.e. as in 'ln -s'). It's a line like:
>>
>> > Link America/New_York US/Eastern
>>
>> If you do
>>
>> % zic -d /tmp/zones src/northamerica
>> % zic -d /tmp/zones src/backward
>> % ls -l /tmp/zones/US/Eastern /tmp/zones/America/New_York
>>
>> -rw-r--r-- 3 ddunham admin 1250 May 5 16:44 /tmp/zones/America/New_York
>> -rw-r--r-- 3 ddunham admin 1250 May 5 16:44 /tmp/zones/US/Eastern
>>
>> It is a real link. It is the same file.
> This is all very nice; but....original question was:
> "were is the source for US/Eastern files?"
Why do you think my answer of "northamerica" is wrong?
Just rename the file it creates to US/Eastern and you've got it, right?
> i.e. where is the TEXT source file from which I would create, using
> zic, the file US/Eastern. It needs to be a text file which has a
> 'ZONE' with US/Eastern!....
What 'ZONE' are you talking about?
Watch this....
% mkdir /tmp/zones
% zic -d /tmp/zones /usr/share/lib/zoneinfo/src/northamerica
% cmp /tmp/zones/America/New_York /usr/share/lib/zoneinfo/US/Eastern
%
They are identical. Just rename or link America/New_York to US/Eastern
and you're done. Running zic on 'backward' will do that for you.
Actually, you don't want the compilation, you just want to search the
source. So northamerica/New_York is what you want.
Mark
The file "/usr/share/lib/zoneinfo/src/northamerica" contains the rule
information.
I am not sure about the backwards-compatibility, but I believe that
"US/Eastern" is the current way, while "America/New_York" is the old
way. It seems that a default system contains "US/Eastern" and not
"America/New_York". But I will stay out of THAT discussion.
One way or the other "US/Eastern" and "America/New_york" are linked.
And we need to use "New_York" in this case.
In the file "northamerica" we need to search for "New_York", you see:
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone America/New_York -4:56:02 - LMT 1883 Nov 18 12:00
-5:00 US E%sT 1920
-5:00 NYC E%sT 1942
-5:00 US E%sT 1946
-5:00 NYC E%sT 1967
-5:00 US E%sT
Assuming that you are interested in the DST-changes after 1967 you are
redirected to the rule "US" with a standard offset of 5 hours from GMT
and "E%sT" format. This format is used together with another variable
(which we will see later) when the date is displayed.
We are interested in the rule "US", search for it with:
# grep Rule northamerica | egrep "US|NAME" | head –11
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule US 1918 1919 - Mar lastSun 2:00 1:00 W # War
Rule US 1918 1919 - Oct lastSun 2:00 0 S
Rule US 1942 only - Feb 9 2:00 1:00 W # War
Rule US 1945 only - Sep 30 2:00 0 S
Rule US 1967 max - Oct lastSun 2:00 0 S
Rule US 1967 1973 - Apr lastSun 2:00 1:00 D
Rule US 1974 only - Jan 6 2:00 1:00 D
Rule US 1975 only - Feb 23 2:00 1:00 D
Rule US 1976 1986 - Apr lastSun 2:00 1:00 D
Rule US 1987 max - Apr Sun>=1 2:00 1:00 D
To find the appropriate rules look in the columns FROM and TO.
Assuming that we are not interested in the past, we find:
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule US 1967 max - Oct lastSun 2:00 0 S
Rule US 1987 max - Apr Sun>=1 2:00 1:00 D
These two rules apply to today.
The second rule starts DST, the first one stops it (why this is true
you will see later);
Columns 3 (FROM) and 4 (TO) specify the years that the rules are
applicable for.
TYPE (column 5) usually will be a dash (see for more info "man zic").
The 6th column (IN) specifies the month in which the rule is applied,
while ON (column 7) specifies the day. In this example the last Sunday
of October and the first Sunday of April.
Column 8 (AT) specifies at what time the rule is executed. At 2
o'clock in the morning in this case.
The 9th column (SAVE) explains the time that has to be added to the
default offset.
The last column is used to distinguish between applied rules. The
letter(s) are used to replace the "%s" in the format as specified in
the Zone.
On June 1rst at 11:00 UTC the date will be shown as: UTC plus the
"Zone GMT-offset" (-5) plus the "Rule Save" (1:00) equals to "UTC-4"
--> Sun Jun 1 7:00:00 EDT 2003
While On December 1rst at 11:00 UTC it shows as : UTC plus the "Zone
GMT-offset" (-5) plus the "Rule Save" (0) equals to "UTC-5" --> Sun
Dec 1 6:00:00 EST 2002.
The timezone format is a contraction from the "Zone Format" (E%sT) and
the "Rule Letter (s)" (In this case S for standard in December and D
for Daylight Saving in June).
Nicolas Duchastel
> In comp.unix.solaris Nicolas Duchastel <ducha...@telecomsys.com> wrote:
> >> > I do see that 'backward' creates a "link" from 'America/New_York' to
> >> > 'US/Eastern' (or is it the opposite !?), but thats in the source text
> >> > file!
> >> > Thats not a file link (i.e. as in 'ln -s'). It's a line like:
>
> >> > Link America/New_York US/Eastern
> >>
> >> If you do
> >>
> >> % zic -d /tmp/zones src/northamerica
> >> % zic -d /tmp/zones src/backward
> >> % ls -l /tmp/zones/US/Eastern /tmp/zones/America/New_York
> >>
> >> -rw-r--r-- 3 ddunham admin 1250 May 5 16:44 /tmp/zones/America/New_York
> >> -rw-r--r-- 3 ddunham admin 1250 May 5 16:44 /tmp/zones/US/Eastern
> >>
> >> It is a real link. It is the same file.
>
> > This is all very nice; but....original question was:
>
> > "were is the source for US/Eastern files?"
>
> Why do you think my answer of "northamerica" is wrong?
>
> Just rename the file it creates to US/Eastern and you've got it, right?
>
> > i.e. where is the TEXT source file from which I would create, using
> > zic, the file US/Eastern. It needs to be a text file which has a
> > 'ZONE' with US/Eastern!....
>
> What 'ZONE' are you talking about?
OK; I am starting to think that there isn't any SOURCE file for
US/Eastern per se :)
wait; just pulling your leg! :)
I now do understand what most posters have been saying: "There is NO
specific US/Eastern source file".
That said, why, oh why! when I install Solaris, I get a binary for
US/Eastern but NOT for America/New_York.
(i.e. see my other comments below)
In other words, I was looking for something like this:
Zone US/Eastern -5:00 EtatsUnis E%sT
Rule EtatsUnis 1967 max - Oct lastSun 2:00 0 S
Rule EtatsUnis 1987 max - Apr Sun>=1 2:00 1:00 D
p.s. I used the token 'EtatsUnis' for the Rule name; just so that we
dont get confused with multiple things being name with the same token:
i.e. 'EtatsUnis' is the Rule token; it doesn't have anything to do
with the fact that the Zone itself is named 'US/Eastern', right?
BUT, this does not and will never exist!
(i.e. rather, there is a line in backwards which states:
Link America/New_York US/Eastern
> Watch this....
>
> % mkdir /tmp/zones
> % zic -d /tmp/zones /usr/share/lib/zoneinfo/src/northamerica
> % cmp /tmp/zones/America/New_York /usr/share/lib/zoneinfo/US/Eastern
> %
Tried it. Thanks.
Learnt from it that the 'LINK' lines in backward actually make hard
links (i.e. I was looking for soft links and thus, this is where some
of my confusion was originating from :)). I did a ls -i on both files
and then saw that they were the same file: i.e. hard link! (i.e.
rather than doing 'cmp' on the files, that what we should do to check:
% ls -li /tmp/zones/America/New_York
/usr/share/lib/zoneinfo/US/Eastern
1965818 America/New_York
1965818 US/Eastern
OK; so if I do this, I understand that I will end-up with 2 files
which will be 100% identiccal (actually, 1 file, with 1 hard link :));
BUT...
to match with any and all of Solaris 8 (or 7) installations that I
have seen, this would mean that people at SUN, when they build
Solaris, do the following:
a) zic /usr/share/lib/zoneinfo/src/northamerica
b) zic /usr/share/lib/zoneinfo/src/backwards
c) rm -fr /usr/share/lib/zoneinfo/America
i.e. when you have a base installation; you dont get the America
dir!!!
WHY!? oh WHY? why do step c)!? why not simply deliver it all!
(p.s. you dont have to answer this; unless you know :) it's more of a
rhetorical rant line :) :) )
Anyway; I really appreciated this; I have learnt way too much for my
good health about time zones and how they are maintained :)
In conclusion, I will be modifying my script such that it can also
look for LINK lines and from them, also build extra entries in my C++
program (or maybe, I should re-design this piece of C++ code which I
inherited: i.e. it shouldn't need to get so close to the timezone
stuff; i.e. it could simply ask the OS for timezone offset and start
and end of daylight saving etc.... BUT that is really my problem only
:) ).
Again, thank you all.
(I am sure that this thread will be usefull to others trying to
figuring out this stuff...).
Tony Walton
>
> That said, why, oh why! when I install Solaris, I get a binary for
> US/Eastern but NOT for America/New_York.
Nicolas, is your news server dropping half the responses to your
questions or something?
Darren alluded to this in Message-ID:
<imDsa.173$4a6.24...@newssvr14.news.prodigy.com> on 2nd May, Chris
mentioned what Solaris 9 delivers as regards timezones in Message-ID:
<b9123t$sn1$1...@pegasus.csx.cam.ac.uk> on 3rd May and answered it fully in
Message-ID: <b969k9$aml$1...@pegasus.csx.cam.ac.uk> on 5th May and I
answered it in Message-ID: <3EB789B...@s-u-n.com> on 6th May.
--
Tony
Alan Coopersmith
|to match with any and all of Solaris 8 (or 7) installations that I
|have seen, this would mean that people at SUN, when they build
|Solaris, do the following:
|
|a) zic /usr/share/lib/zoneinfo/src/northamerica
|b) zic /usr/share/lib/zoneinfo/src/backwards
|c) rm -fr /usr/share/lib/zoneinfo/America
Not quite. Step (c) is actually pkgmk with the list of zone files that
Solaris supports. When the Olson master sources add new zones, manual
intervention is required to add them to this list if they are desired in
Solaris. The US/* zone files are the names Sun has used for years, so
must be supported for backwards compatibility.
--
________________________________________________________________________
Alan Coopersmith al...@alum.calberkeley.org
http://www.CSUA.Berkeley.EDU/~alanc/ aka: Alan.Coo...@Sun.COM
Working for, but definitely not speaking for, Sun Microsystems, Inc.
Paul Eggert
> Solaris will parse EST5EDT as a POSIX string (and will parse
> :EST5EDT - with leading colon - as an Olson file of that name).
But EST5EDT is not a POSIX TZ string. POSIX says that if you specify
a daylight-saving time, you must also give the transition rules.
Since EST5EDT does not conform to POSIX, Solaris is allowed to do with
it as it pleases.
Solaris apparently uses a different method than the vanilla Olson code
for TZ='EST5EDT'. Perhaps Solaris is assuming the current US rules,
but if so, that's unwise, as it won't survive the next US rule change
gracefully.
Villy Kruse
Paul Eggert <egg...@twinsun.com> wrote:
>Tony Walton <tony....@s-u-n.com> writes:
>
>> Solaris will parse EST5EDT as a POSIX string (and will parse
>> :EST5EDT - with leading colon - as an Olson file of that name).
>
>But EST5EDT is not a POSIX TZ string. POSIX says that if you specify
>a daylight-saving time, you must also give the transition rules.
>Since EST5EDT does not conform to POSIX, Solaris is allowed to do with
>it as it pleases.
>
The summertime rules are usualy optional and the US rules at the time
the library is compiled is the default summertime rule. Thus, to specify
the US Eastern time zone on a SystemV or AIX systems without Olson tables
you have always used "TZ=EST5EDT"
Villy
Dave Uhring
> i.e. my goal is to search for all text source files in
> /usr/share/lib/zoneinfo and then parse each file looking for the last
> RULE for any given ZONE; and presto, I can build some C++ program
> which contains the same information I need (i.e.. dont worry about why
> I am doing that; its designed that way :), please, just focus on the
> question: is there a source file !?)
Try this source, the one for Solaris is available only with difficulty
and/or expense.
ftp://ftp1.freebsd.org/pub/FreeBSD/branches/4.0-stable/src/share/zoneinfo/
Villy Kruse
Why? When it is easily available from the true source
ftp://elsie.nci.nih.gov/pub/tzdata2003a.tar.gz
Villy
Richard L. Hamilton
You don't even need to do that (although it's good to keep in mind where
that can be found). Assuming you have Solaris 8, the source for
"US/Eastern" is actually in two files:
/usr/share/lib/zoneinfo/src/northamerica
(which defines America/New_York)
and
/usr/share/lib/zoneinfo/src/backward
(which defines US/Eastern as a backwards compatibility
link to America/New_York; the naming convention changed sometime ago)
Both are in package SUNWcsu, so they should already be
on the system.
On Solaris 2.5.1 (SunOS 5.5.1), there's no src subdirectory;
the files are right in /usr/share/lib/zoneinfo, but everything
else is the same. I'm not sure at what version they moved down
into a src subdirectory.
--
mailto:rlh...@mindwarp.smart.net http://www.smart.net/~rlhamil
Paul Eggert
> my goal is to search for all text source files in
> /usr/share/lib/zoneinfo and then parse each file looking for the last
> RULE for any given ZONE
That's not a good idea in general. For example, the last two RULE
lines for the zone Asia/Tehran are:
Rule Iran 2036 2037 - Mar 21 0:00 1:00 D
Rule Iran 2036 2037 - Sep 21 0:00 0 S
If you use those rules this year, you'll be off by a day.
> presto, I can build some C++ program which contains the same
> information I need (i.e.. dont worry about why I am doing that; its
> designed that way :)
It sounds like you're doing the same thing the Java folks did: you're
reinventing time zones with less functionality than Olson's code.
If you really want to go down that route, I suppose you can modify
zic.c (in the tz distribtion) or Vzic. See
<http://www.twinsun.com/tz/tz-link.htm> for more info about these
programs.