From: yan...@alpha2.csd.uwm.edu (Scott A Yanoff)
Subject: Why does strftime() nad others return in GMT?
Date: 1995/06/08
Message-ID: <3r7hpg$bl9@uwm.edu>#1/1
X-Deja-AN: 104034318
organization: University of Wisconsin - Milwaukee
reply-to: yan...@alpha2.csd.uwm.edu
newsgroups: alt.sys.sun,comp.sys.sun.admin,comp.sys.sun.misc,comp.unix.questions
originator: yan...@alpha2.csd.uwm.edu
I use strftime() and even if I just make a system call to the
date command, it always returns the date in GMT
(and I have TZ=US/Central)
I have even tried a shell script:
#!/bin/sh
TZ=US/Central
date
but it still returns in GMT...
any ideas?
I really aprpeciate any help..
-Scott Yanoff
--
_/\ _ !\ _ @ Milwaukee, WI - A Great Place On a Great Lake
! _! !! ! !_ ~~ @ ~ ~~
! ! ! !! ! ! !~~__=||_~ ~~~
! ! ! _! ! ~~~ ~\____/ ~~~ yan...@csd.uwm.edu yan...@cs.uwm.edu
From: b...@Starbase.NeoSoft.COM (Brad Morrison)
Subject: Re: Why does strftime() nad others return in GMT?
Date: 1995/06/08
Message-ID: <3r7rnp$o8n@Starbase.NeoSoft.COM>#1/1
X-Deja-AN: 104034330
references: <3r7hpg$bl9@uwm.edu>
organization: NeoSoft Internet Services +1 713 968 5800
newsgroups: alt.sys.sun,comp.sys.sun.admin,comp.sys.sun.misc,comp.unix.questions
In article <3r7hpg$...@uwm.edu>,
Scott A Yanoff <yan...@alpha2.csd.uwm.edu> wrote:
>I use strftime() and even if I just make a system call to the
>date command, it always returns the date in GMT
>(and I have TZ=US/Central)
Where did you get "US/Central" for a $TZ value? Am I out of date, or is
the format not CST6CDT (CST6CST if you don't want Daylight Savings Time)?
>I have even tried a shell script:
>#!/bin/sh
>TZ=US/Central
>date
Even if your $TZ value was correct (I don't know of a UNIX variant which
respects this notation, WTPE of AIX), you didn't export it; it remains
local and 'date' can't see it.
>but it still returns in GMT...
>any ideas?
Time for a scan of /usr/share/lib/zoneinfo:
1. ls -il /usr/share/lib/zoneinfo/localtime
If this file is not found, link /usr/share/lib/zoneinfo/CST6CDT to it, along
with /usr/share/lib/zoneinfo/US/Central (ah-HAH! So, that's where you got
that bogus TZ value...)
2. If the file *is* found, you can do some detective work: use the inode from
'ls -il' above to find links to localtime, viz:
find /usr -inum <number from above> -print
I suspect that there are no links, since GMT is a default.
>I really aprpeciate any help..
>-Scott Yanoff
No sweat; too bad this isn't in man pages.
--
"Push to test." Brad Morrison: b...@neosoft.com, morri...@paranet.com
<click> "I put one in each eye and two up each nostril."
"Release to detonate." --Agent Cooper
From: egg...@twinsun.com (Paul Eggert)
Subject: Re: Why does strftime() nad others return in GMT?
Date: 1995/06/08
Message-ID: <3r8a80$e92@spot.twinsun.com>#1/1
X-Deja-AN: 104034344
references: <3r7hpg$bl9@uwm.edu> <3r7rnp$o8n@Starbase.NeoSoft.COM>
organization: Twin Sun Inc, El Segundo, CA, USA
newsgroups: alt.sys.sun,comp.sys.sun.admin,comp.sys.sun.misc,comp.unix.questions
b...@Starbase.NeoSoft.COM (Brad Morrison) writes:
>Where did you get "US/Central" for a $TZ value?...
>(I don't know of a UNIX variant which respects this notation, WTPE of AIX)
SunOS/Solaris has supported TZ='US/Central' for quite some time.
This notation is a valid extension to the Posix standard for TZ.
It is very common among Unix variants (e.g. SVR4, 4.4BSD, Linux),
though some require TZ=':US/Central' because of a misinterpretation
of the Posix standard.
See <ftp://elsie.nci.nih.gov/pub/tz/> for the latest and greatest
timezone tables in the 'US/Central' tradition. They're much
easier to use than Posix strings, particularly if your
daylight savings rules don't match the US's.
From: mbr...@austin.ibm.com (Mark Brown)
Subject: Re: Why does strftime() nad others return in GMT?
Date: 1995/06/09
Message-ID: <D9xB0y.ts3@austin.ibm.com>#1/1
X-Deja-AN: 104150633
sender: n...@austin.ibm.com (News id)
references: <3r7hpg$bl9@uwm.edu> <3r7rnp$o8n@Starbase.NeoSoft.COM>
<3r8a80$e92@spot.twinsun.com>
organization: IBM Corp., Austin TX
newsgroups: alt.sys.sun,comp.sys.sun.admin,comp.sys.sun.misc,comp.unix.questions
> egg...@twinsun.com (Paul Eggert) writes:
>b...@Starbase.NeoSoft.COM (Brad Morrison) writes:
>>Where did you get "US/Central" for a $TZ value?...
>>(I don't know of a UNIX variant which respects this notation, WTPE of AIX)
>
>SunOS/Solaris has supported TZ='US/Central' for quite some time.
>This notation is a valid extension to the Posix standard for TZ.
>It is very common among Unix variants (e.g. SVR4, 4.4BSD, Linux),
>though some require TZ=':US/Central' because of a misinterpretation
>of the Posix standard.
Ummm. I don't think so. IEEE 1003.1-1990 is very clear on this point:
Section 8.1.1, lines 54 - 112 do *NOT* allow for what you say above. I
also know of *NO* interpretation (and I have a complete collection of
the published ones in front of me) that allows the behavior you
describe. There are two possible conforming formats, and yours ain't one
of them. In fact, 1003.1 Interp 41 makes it clear that the *only*
allowed format that does not begin with a ":" character is the "std
offset dst ..." one.
Now, certainly an implementation is allowed to support other TZ formats
-- but they are not POSIX formats.
BTW: AIX doesn't support this format ('US/Central') either.
cheers,
Mark Brown
--
Mark Brown | AIX Architecture | Civil Liberty
(512) 838-3926 | 11400 Burnet Rd M/S 9582 | Through
T/L 678-3926 | Austin, TX 78758 | Complex Mathematics!
mbr...@austin.ibm.com -or- MBROWN at AUSVM6 |
From: egg...@twinsun.com (Paul Eggert)
Subject: Re: Why does strftime() nad others return in GMT?
Date: 1995/06/12
Message-ID: <3rj4vg$q1r@spot.twinsun.com>#1/1
X-Deja-AN: 104315003
references: <3r7hpg$bl9@uwm.edu> <3r7rnp$o8n@Starbase.NeoSoft.COM>
<3r8a80$e92@spot.twinsun.com> <D9xB0y.ts3@austin.ibm.com>
organization: Twin Sun Inc, El Segundo, CA, USA
newsgroups: alt.sys.sun,comp.sys.sun.admin,comp.sys.sun.misc,comp.unix.questions
mbr...@austin.ibm.com (Mark Brown) writes:
>> egg...@twinsun.com (Paul Eggert) writes:
>>SunOS/Solaris has supported TZ='US/Central' for quite some time.
>>This notation is a valid extension to the Posix standard for TZ.
>>It is very common among Unix variants (e.g. SVR4, 4.4BSD, Linux),
>>though some require TZ=':US/Central' because of a misinterpretation
>>of the Posix standard.
>Ummm. I don't think so. IEEE 1003.1-1990 is very clear on this point:
>Section 8.1.1, lines 54 - 112 do *NOT* allow for what you say above.
Now I know why IBM does not support this useful extension -- the OS
lawyers got to you (:-). But sorry, you (and apparently IBM) have
misinterpreted what Posix conformance means. TZ='US/Central' is not
one of the forms listed in 8.1.1, so the implementation is free to
interpret TZ='US/Central' as an extension.
For further discussion on this issue, please see IEEE 1003.1-1990
section B.8.1.1, page 284, lines 4195-4201, which approvingly mentions
the TZ='US/Central' tradition under the name ``the Olson/Harris
method''. The key point is that, so long as the Olson/Harris code
parses the Posix-mandated TZ strings correctly (which it does),
it can do what it likes with other strings like 'US/Central'.
While we're on the subject, vendors who ignore TZ-setting convenience
are missing the boat if they want to sell outside the US. It is much
more convenient for a user in (for example) Israel to set
TZ='Asia/Tel_Aviv' than to try to figure out what hieroglyphics to put
into the silly Posix TZ string this year. This is why Unix-like
systems are tending to support the Olson tables in one form or
another. I know Unixware, Solaris, Nextstep, and Linux do, and I'm
sure there are others.
From: mbr...@austin.ibm.com (Mark Brown)
Subject: Re: Why does strftime() nad others return in GMT?
Date: 1995/06/13
Message-ID: <DA484p.9rJ@austin.ibm.com>#1/1
X-Deja-AN: 104314971
sender: n...@austin.ibm.com (News id)
references: <3r8a80$e92@spot.twinsun.com> <D9xB0y.ts3@austin.ibm.com>
<3rj4vg$q1r@spot.twinsun.com>
organization: IBM Corp., Austin TX
newsgroups: alt.sys.sun,comp.sys.sun.admin,comp.sys.sun.misc,comp.unix.questions
What Paul says in this posting is correct...but it is not what he
claimed in his original posting, thus the followup....
> egg...@twinsun.com (Paul Eggert) writes:
>mbr...@austin.ibm.com (Mark Brown) writes:
>>> egg...@twinsun.com (Paul Eggert) writes:
>>>SunOS/Solaris has supported TZ='US/Central' for quite some time.
>>>This notation is a valid extension to the Posix standard for TZ.
It is (just as I said in my previous post on this subject) a valid
*implementation* extension, but this extension is not POSIX. You
snipped that part of my post...
>>>It is very common among Unix variants (e.g. SVR4, 4.4BSD, Linux),
>>>though some require TZ=':US/Central' because of a misinterpretation
>>>of the Posix standard.
They require it because they know it is conformant and portable under
POSIX, where TZ='US/Central' is not. This is not a misinterpretation.
They appear to have chosen to put development effort into something
other than non-portable extensions to TZ.
>>Ummm. I don't think so. IEEE 1003.1-1990 is very clear on this point:
>>Section 8.1.1, lines 54 - 112 do *NOT* allow for what you say above.
>
>Now I know why IBM does not support this useful extension -- the OS
>lawyers got to you (:-). But sorry, you (and apparently IBM) have
>misinterpreted what Posix conformance means. TZ='US/Central' is not
>one of the forms listed in 8.1.1, so the implementation is free to
>interpret TZ='US/Central' as an extension.
This is true, and I said it in my posting (the part you left out).
Whether or not AIX chooses to support Olson/Harris is an implementation
issue for IBM. IBM appears to have chosen to stick to known portable
behaviors in this area.
>For further discussion on this issue, please see IEEE 1003.1-1990
>section B.8.1.1, page 284, lines 4195-4201, which approvingly mentions
>the TZ='US/Central' tradition under the name ``the Olson/Harris
>method''. The key point is that, so long as the Olson/Harris code
>parses the Posix-mandated TZ strings correctly (which it does),
>it can do what it likes with other strings like 'US/Central'.
This is what I said.
Please note, while you are at this, that Appendix B is Rationale, and
thus is not part of the Standard, and is not binding on the standard.
>While we're on the subject, vendors who ignore TZ-setting convenience
>are missing the boat if they want to sell outside the US. It is much
>more convenient for a user in (for example) Israel to set
>TZ='Asia/Tel_Aviv' than to try to figure out what hieroglyphics to put
>into the silly Posix TZ string this year.
It may be convenient, but it sure isn't portable. Scripts that use this
are not going to work across systems.
cheers,
mark
--
Mark Brown | AIX Architecture | Civil Liberty
(512) 838-3926 | 11400 Burnet Rd M/S 9582 | Through
T/L 678-3926 | Austin, TX 78758 | Complex Mathematics!
mbr...@austin.ibm.com -or- MBROWN at AUSVM6 |
From: egg...@twinsun.com (Paul Eggert)
Subject: Re: Why does strftime() nad others return in GMT?
Date: 1995/06/13
Message-ID: <3rki8r$qvu@spot.twinsun.com>#1/1
X-Deja-AN: 104314982
references: <3r8a80$e92@spot.twinsun.com> <D9xB0y.ts3@austin.ibm.com>
<3rj4vg$q1r@spot.twinsun.com> <DA484p.9rJ@austin.ibm.com>
organization: Twin Sun Inc, El Segundo, CA, USA
newsgroups: alt.sys.sun,comp.sys.sun.admin,comp.sys.sun.misc,comp.unix.questions
mbr...@austin.ibm.com (Mark Brown) writes:
>>>> egg...@twinsun.com (Paul Eggert) writes:
>>>>It is very common among Unix variants (e.g. SVR4, 4.4BSD, Linux),
>>>>though some require TZ=':US/Central' because of a misinterpretation
>>>>of the Posix standard.
>They require it because they know it is conformant and portable under
>POSIX, where TZ='US/Central' is not. This is not a misinterpretation.
``Portable'' in what sense? Posix does not define the behavior
of TZ=':US/Central', so it isn't ``portable'', in the sense that
Posix doesn't guarantee that it will work as desired.
If you really want a portable TZ string for US Central time, then you
must use a complicated TZ string. (Posix does not guarantee that
TZ='CST6CDT' will do what you want -- you need a longer set of
hieroglyphics to be truly portable.)
Similarly, the Posix standard does not define the behavior of TZ='US/Central';
just as with TZ=':US/Central', it may do what you want, or it may not.
So a vendor who requires that users set TZ=':US/Central'
instead of the traditional TZ='US/Central', and who in response to
user complaints says ``Posix made me do it'', is misinterpreting
the standard: Posix does not require that the implementation reject
TZ='US/Central'. This is the misinterpretation that I was objecting
to in the above quote.
>>While we're on the subject, vendors who ignore TZ-setting convenience
>>are missing the boat if they want to sell outside the US...
>It may be convenient, but it sure isn't portable.
There is generally a tradeoff between portability and convenience,
and users must choose one or the other. In practice, more people
use nonportable TZ strings like 'US/Central' or 'CST6CDT' than use
portable ones like 'JST-9'.
It puzzles me that a few vendors still refuse to support convenience,
despite user requests, despite its widespread use by the competition,
despite a de facto standard, and despite the existence of public domain
source code for the de facto standard. I know that it's just a small
convenience, but small conveniences add up....
From: g...@netapp.com (Guy Harris)
Subject: Re: Why does strftime() nad others return in GMT?
Date: 1995/06/13
Message-ID: <3rlbu8$j3g@nova.netapp.com>#1/1
X-Deja-AN: 104315028
references: <3r8a80$e92@spot.twinsun.com> <D9xB0y.ts3@austin.ibm.com>
<3rj4vg$q1r@spot.twinsun.com> <DA484p.9rJ@austin.ibm.com>
organization: Network Appliance Corporation
newsgroups: alt.sys.sun,comp.sys.sun.admin,comp.sys.sun.misc,comp.unix.questions
Mark Brown <mbr...@austin.ibm.com> wrote:
>Whether or not AIX chooses to support Olson/Harris is an implementation
>issue for IBM.
I've no idea where this "Olson/Harris" stuff came from - yes, 1003.1
calls it that in the Rationale, but I've no idea where *they* got it
from - but, just to set the record straight, Arthur Olson, and perhaps
some others, deserve the credit for the idea; I thought (and still do
think) it's the Right Way To Implement Time Zones, so I joined in on
some of the implementation work (the first thing I did was to put the
files in a standard byte order), and got it into SunOS 4.0, but *I*
shouldn't be given any credit for the idea.
Arthur also did, by far, the bulk of the implementation, and plenty of
people other than me contributed to the implementation - I think some of
them contributed at least as much as I did, if not more.
>IBM appears to have chosen to stick to known portable behaviors in this
>area.
There is nothing "nonportable" about implementing both the POSIX syntax
and the Olson scheme. A program that relies on the Olson scheme being
present may be nonportable, but very few programs rely on that.
(Are there, in fact, *any* programs or scripts that rely on the syntax
of TZ? An example given by those who argued in favor of having POSIX
bother to standardize the syntax of TZ was "what about a program that
wants to use New York City time, e.g. because it deals with the stock
market", but, unless that program is re-released every time the time
zone rules in the USA change, it'd have to allow the user to specify the
time zone string - and, if so, it might as well just let you stick
"US/Eastern" or "America/New_York" or whatever in there.)
I.e., I see no reason why IBM gains from "sticking to known portable
behaviors in this area". Heck, I even managed to beat AT&T into picking
the Olson stuff up for SVR4.0 - and it appears to be the *default*
scheme in SVR4.2.
From: mbr...@austin.ibm.com (Mark Brown)
Subject: Re: Why does strftime() nad others return in GMT?
Date: 1995/06/14
Message-ID: <DA63tK.qxz@austin.ibm.com>#1/1
X-Deja-AN: 104451303
sender: n...@austin.ibm.com (News id)
references: <3rj4vg$q1r@spot.twinsun.com> <DA484p.9rJ@austin.ibm.com>
<3rki8r$qvu@spot.twinsun.com>
organization: IBM Corp., Austin TX
newsgroups: alt.sys.sun,comp.sys.sun.admin,comp.sys.sun.misc,comp.unix.questions
> egg...@twinsun.com (Paul Eggert) writes:
>mbr...@austin.ibm.com (Mark Brown) writes:
>``Portable'' in what sense? Posix does not define the behavior
>of TZ=':US/Central', so it isn't ``portable'', in the sense that
>Posix doesn't guarantee that it will work as desired.
Truth.
>If you really want a portable TZ string for US Central time, then you
>must use a complicated TZ string. (Posix does not guarantee that
>TZ='CST6CDT' will do what you want -- you need a longer set of
>hieroglyphics to be truly portable.)
Truth. But, the point remains, that you *can* guarantee portability with
a POSIX string. You cannot with yours.
>So a vendor who requires that users set TZ=':US/Central'
>instead of the traditional TZ='US/Central', and who in response to
>user complaints says ``Posix made me do it'', is misinterpreting
>the standard: Posix does not require that the implementation reject
>TZ='US/Central'. This is the misinterpretation that I was objecting
>to in the above quote.
The Standard requires that an implementation *accept* certain inputs,
states how those inputs will be handled. The implementation is free to
*reject* all other inputs.
Hence, using a non-standard format risks non-portability.
>There is generally a tradeoff between portability and convenience,
>and users must choose one or the other. In practice, more people
>use nonportable TZ strings like 'US/Central' or 'CST6CDT' than use
>portable ones like 'JST-9'.
Our European customers tend to prefer a fully-specified format:
std offset dst offset Mm.n.d/time,Mm.n.d/time
because it *always* works. I know this because I have had to fix bugs we
had in AIX related to this.
>It puzzles me that a few vendors still refuse to support convenience,
>despite user requests, despite its widespread use by the competition,
>despite a de facto standard, and despite the existence of public domain
>source code for the de facto standard. I know that it's just a small
>convenience, but small conveniences add up....
I can support the Standard format, or confuse my customers, and dilute
my resource, supporting every new format that comes along....
cheers,
mark
--
Mark Brown | AIX Architecture | Civil Liberty
(512) 838-3926 | 11400 Burnet Rd M/S 9582 | Through
T/L 678-3926 | Austin, TX 78758 | Complex Mathematics!
mbr...@austin.ibm.com -or- MBROWN at AUSVM6 |
From: egg...@twinsun.com (Paul Eggert)
Subject: Re: Why does strftime() nad others return in GMT?
Date: 1995/06/15
Message-ID: <3rqdjo$6j6@spot.twinsun.com>#1/1
X-Deja-AN: 104451334
references: <3rj4vg$q1r@spot.twinsun.com> <DA484p.9rJ@austin.ibm.com>
<3rki8r$qvu@spot.twinsun.com> <DA63tK.qxz@austin.ibm.com>
organization: Twin Sun Inc, El Segundo, CA, USA
newsgroups: alt.sys.sun,comp.sys.sun.admin,comp.sys.sun.misc,comp.unix.questions
mbr...@austin.ibm.com (Mark Brown) writes:
>Our European customers tend to prefer a fully-specified format:
> std offset dst offset Mm.n.d/time,Mm.n.d/time
>because it *always* works. I know this because I have had to fix bugs we
>had in AIX related to this.
... which meant that it doesn't *always* work. (:-)
I'm afraid old AIX systems are not the only ones with bugs in this area.
For a maximally portable real-world application that needs to set TZ,
it's better to try the Olson extension first,
and fall back on Posix if the host doesn't support it.
This is more portable than assuming either Posix or Olson.
If you're a system administrator who is setting the default timezone of a host,
it's better to use the Olson extension if it's supported on that host.
One reason for preferring the Olson extension
is that straight Posix doesn't *always* work --
for example, it fails to handle the previous year's times correctly
if the political authorities have changed time zone rules since then,
or if the rules don't fit into the Posix straightjacket
(which happens in places like Britain and Israel).
The Olson extension doesn't have this problem.
>I can support the Standard format, or confuse my customers,....
I've found that most customers are more confused
by the standard Posix format than by the Olson extension.
For example, I would say that most customers in Israel
are less confused by entering something like 'Asia/Tel_Aviv',
than by having to enter some complicated TZ value like, er, ...
(what exactly is this year's correct Posix string for Israel again? :-)
and worse, having to enter a new TZ value every year.
>and dilute my resource, supporting every new format that comes along....
This may be exaggerating the difficulties a bit.
No other TZ format has been seriously proposed.
It's not much work to add support for the Olson extension,
since the Olson code is public domain, and is widely used by other vendors.
I don't think the extension dilutes their resources in any real way;
on the contrary, I expect that it pays for itself
by reducing the burden on their customer support.