From: wa...@clark.net (Tim Waire)
Subject: Daylight Savings Time
Date: 1995/07/26
Message-ID: <3v63gr$ph1@clark.net>#1/1
X-Deja-AN: 107032091
organization: Clark Internet Services, Inc., Ellicott City, MD USA
content-type: TEXT/PLAIN; charset=ISO-8859-1
mime-version: 1.0
newsgroups: comp.unix.aix
This is sorta an off-the-wall question. We have a real-time system that
is highly date/time dependent.
One of our IS folks is curious how a change in the date of when daylight
savings time is applied would be handled? Would IBM have to provide a
PTF? Basically, what if the dates move from September and June as
currently defined.
All it takes for this date to change is a mandate from Congress. I
understand they did just that during the 70's oil embargo. In the how of
adding daylight hours to spare heating fuel.
Thanks for any input.
/taw
--
Tim Waire FidoNet: 1:261/1138
CyberSoft, LLC Internet: wa...@cybermac.com
P.O. Box 5001 Voice: (410) 893-5343
Glen Arm, MD 21057 USA CyberMac - A FirstClass BBS: (410) 668-3903
From: sw...@boco.co.gov (Shane Castle)
Subject: Re: Daylight Savings Time
Date: 1995/07/27
Message-ID: <3v8acc$1td4@bcx01.boco.co.gov>#1/1
X-Deja-AN: 107032012
references: <3v63gr$ph1@clark.net>
organization: Boulder County Tech Svcs, Boulder CO USA
reply-to: sw...@boco.co.gov (Shane Castle)
newsgroups: comp.unix.aix
In comp.unix.aix, Tim Waire<wa...@clark.net> wrote:
>One of our IS folks is curious how a change in the date of when daylight
>savings time is applied would be handled? Would IBM have to provide a
>PTF? Basically, what if the dates move from September and June as
>currently defined.
Already handled in AIX 3.2.5; see "man 5 environment" for info on the
TZ environment variable. Essentially, you can custom-define rules for
when to change to/from DST and at what time of day the change occurs.
This is required because AIX and RS/6000s are sold all over the world,
not just in the USA.
--
Shane Castle | "Perfection, then, is finally achieved, not
Boulder County Info Svcs | when there is nothing left to add, but when
Boulder CO USA | there is nothing left to take away."
| - Antoine de Saint-Exupéry
From: egg...@twinsun.com (Paul Eggert)
Subject: Re: Daylight Savings Time
Date: 1995/07/28
Message-ID: <3vbv19$2s0@shade.twinsun.com>#1/1
X-Deja-AN: 107032083
references: <3v63gr$ph1@clark.net> <3v8acc$1td4@bcx01.boco.co.gov>
organization: Twin Sun Inc, El Segundo, CA, USA
newsgroups: comp.unix.aix
sw...@boco.co.gov (Shane Castle) writes:
>In comp.unix.aix, Tim Waire<wa...@clark.net> wrote:
>>One of our IS folks is curious how a change in the date of when daylight
>>savings time is applied would be handled?...
>Already handled in AIX 3.2.5; see "man 5 environment" for info on the
>TZ environment variable.
Sorry, it's not fully handled, since it causes AIX to report incorrect
values for timestamps taken from earlier years (i.e. before the
daylight savings time rules were changed).
It would be better to have the complete daylight savings time history,
so that timestamps could be reported correctly no matter when they occurred.
That is how Unix traditionally did things, and that tradition is maintained
in many OSes (e.g. Solaris, Unixware, and even Linux). There is a
public domain package that IBM could use to add support for this; see
<ftp://elsie.nci.nih.gov/pub/tz*>. Unfortunately, though, AIX is still
stuck in the Posix dark ages on this particular issue.
From: Robert Schnee <100673....@CompuServe.COM>
Subject: Re: Daylight Savings Time
Date: 1995/08/07
Message-ID: <404cjt$nv8$1@mhadf.production.compuserve.com>#1/1
X-Deja-AN: 107625960
references: <3v63gr$ph1@clark.net>
organization: CompuServe, Inc. (1-800-689-0736)
newsgroups: comp.unix.aix
IBM is providing hardcoded daylight change dates for USA only -
even when the selected timezone is not a USA one.
For all other there must be added an entry in the TZ variable in
/etc/environment file to get the change on the right day (Europe
is going to daylight time on different day).
I will be not a big deal to change the TZ when the dates move -
later there must be PTF from IBM.
--
=================
Robert Schnee
100673....@compuserve.com
From: egg...@twinsun.com (Paul Eggert)
Subject: Re: Daylight Savings Time
Date: 1995/08/07
Message-ID: <4063nv$ff7@shade.twinsun.com>#1/1
X-Deja-AN: 107682667
references: <3v63gr$ph1@clark.net> <404cjt$nv8$1@mhadf.production.compuserve.com>
organization: Twin Sun Inc, El Segundo, CA, USA
newsgroups: comp.unix.aix
Robert Schnee <100673....@CompuServe.COM> writes:
>It will be not a big deal to change the TZ when the dates move -
I'm not sure I agree. Yes, once you know what to do, it's not a big
deal to fix one host. But if you sum over all the people who have to
learn how to make the change, and over all the hosts they have to
change, and over all the hosts that won't be changed in time or won't
be changed correctly, then it's a nontrivial cost to IBM's customers
(not to mention IBM's support staff :-).
By the way, I just found out that DEC's OpenVMS V7.0 will support the
public domain Olson TZ extensions; these simplify the handling of
timezone settings, since you can just set your TZ to `Europe/Paris'
(or whatever) and then forget it. (See <ftp://elsie.nci.nih.gov/pub/tz*>.)
This is in addition to the Solaris, Unixware, etc. hosts that already
support the Olson extensions. Now if we could just talk the AIX
maintainers into it....
From: hamish@hamish (Hamish Marson)
Subject: Re: Daylight Savings Time
Date: 1995/08/14
Message-ID: <40m5uf$1d67@thebes.waikato.ac.nz>#1/1
X-Deja-AN: 108079714
sender: ham...@waikato.ac.nz
references: <3v63gr$ph1@clark.net> <404cjt$nv8$1@mhadf.production.compuserve.com>
<4063nv$ff7@shade.twinsun.com>
organization: The University of Waikato
reply-to: ham...@waikato.ac.nz
newsgroups: comp.unix.aix
Paul Eggert (egg...@twinsun.com) wrote:
: Robert Schnee <100673....@CompuServe.COM> writes:
: >It will be not a big deal to change the TZ when the dates move -
: I'm not sure I agree. Yes, once you know what to do, it's not a big
: deal to fix one host. But if you sum over all the people who have to
: learn how to make the change, and over all the hosts they have to
: change, and over all the hosts that won't be changed in time or won't
: be changed correctly, then it's a nontrivial cost to IBM's customers
: (not to mention IBM's support staff :-).
: By the way, I just found out that DEC's OpenVMS V7.0 will support the
: public domain Olson TZ extensions; these simplify the handling of
: timezone settings, since you can just set your TZ to `Europe/Paris'
: (or whatever) and then forget it. (See <ftp://elsie.nci.nih.gov/pub/tz*>.)
: This is in addition to the Solaris, Unixware, etc. hosts that already
: support the Olson extensions. Now if we could just talk the AIX
: maintainers into it....
Apparently AIX plans to stay POSIX compliant on this one....
--
======================================================================
| Hamish Marson |
| Systems Programmer & News Manager n...@news.waikato.ac.nz|
| Computer Services | INTERNET h.mar...@waikato.ac.nz |
| University of Waikato | PHONE +64 7 8562889 xt 8181 |
| New Zealand | FAX +64 7 8384066 |
===========Disclaimer :- Remember. You heard it here first.===========
If nuclear bombs are so safe why don't the French test them under Paris
From: egg...@twinsun.com (Paul Eggert)
Subject: Re: Daylight Savings Time
Date: 1995/08/13
Message-ID: <40mq90$5gb@shade.twinsun.com>#1/1
X-Deja-AN: 108079719
references: <3v63gr$ph1@clark.net> <404cjt$nv8$1@mhadf.production.compuserve.com>
<4063nv$ff7@shade.twinsun.com> <40m5uf$1d67@thebes.waikato.ac.nz>
organization: Twin Sun Inc, El Segundo, CA, USA
newsgroups: comp.unix.aix
hamish@hamish (Hamish Marson) writes:
>Apparently AIX plans to stay POSIX compliant on this one....
It's more accurate to say that the AIX maintainers do not currently
plan to do any more than what Posix requires. The Olson TZ extensions
are not incompatible with Posix; they're merely an extension to the
Posix TZ syntax. Other vendors (DEC, Novell, Sun, etc.) support the
Olson TZ extensions while maintaining Posix compliance. It's not
that hard -- the code and tables to do it correctly are in the public
domain.