daylight saving time patch

[Rick]

hi all,
does anyone know if there is a patch available for open server 5.0.6 for the
new daylight saving time rules beginning in march 2007 and if so where can i
get it.
i looked at sco.com and all i everything i found related to open server
5.0.7

tia

[Jean-Pierre Radley]

Rick typed (on Wed, Feb 07, 2007 at 02:37:57PM -0600):

For the NorthAmerican Eastern Time Zone:

Edit /etc/TIMEZONE

from: TZ=EST5EDT
to: TZ=EST5EDT,M3.2.0/2,M11.1.0/2

--
JP
==> http://www.frappr.com/cusm <==

[Rick]

"Jean-Pierre Radley" <j...@jpr.com> wrote in message
news:2007020721...@jpradley.jpr.com...

thanks JP

[beet...@gmail.com]

JP,

Will this edit of TIMEZONE work for 5.0.4, 5.0.6. 5.0.7, 6? Is there
any way to test or need to?

Thank you very much!
beetle.vw

[Dan Martin]

Hello Rick,

Try using "asktime" to set date and time to
200703110159.55

Then wait 5 seconds and see what "date" reports.

It should tell you 3:00 a.m. for your time zone, with
daylight savings time. eg, PDT, CDT, EDT

Do the same time of day test for 11/4/07 to confirm
that the time falls back to 1:00, for standard time, PST, CST, EST.

For Unixware, I think you'd put the value for TZ in /etc/profile.
I suppose, though I'm not sure, that this is where you'd make
the change for OSR6.

Good luck,
Dan Martin

[ThreeStar]

Yes. I've tested it back to 4.2 and forward to 6.

The only limitation I've found is that it's wise to reboot the system
so that init is aware of the change. I couldn't find any signals that
would force it to re-read TIMEZONE. One consequence is that new /bin/
sh logins inherit the TZ variable that existed at bootup, unless of
course you explicitly source /etc/TIMEZONE in your profiles.

--R Robert

[mark_s...@hotmail.com]

Interestingly I heard today from our local SCO reseller today, after
contacting him for other reasons, that SCO reps told him the
following:

"Version 6 & 5.0.7 patches are available for download at no extra
charge.
For retired products, such as OpenServer 5.0.6 there is a charge.
The
charge is $1995.00 and can be used for 10 different servers."

I don't know anymore details than that. I don't know how valid this is
as I don't see any mention of it at sco.com.

I have tested the TZ fix mentioned in this group, and it appeared to
be great for the OS, not sure about some of our apps if they use TZ or
do it themselves..

Mark

[Jean-Pierre Radley]

mark_s...@hotmail.com typed (on Thu, Feb 08, 2007 at 02:00:07PM -0800):

| On Feb 7, 2:37 pm, "Rick" <rcampb...@sostexas.com> wrote:
| > hi all,
| > does anyone know if there is a patch available for open server 5.0.6 for the
| > new daylight saving time rules beginning in march 2007 and if so where can i
| > get it.
| > i looked at sco.com and all i everything i found related to open server
| > 5.0.7
|

| Interestingly I heard today from our local SCO reseller today, after
| contacting him for other reasons, that SCO reps told him the
| following:
|
| "Version 6 & 5.0.7 patches are available for download at no extra
| charge.
| For retired products, such as OpenServer 5.0.6 there is a charge.
| The
| charge is $1995.00 and can be used for 10 different servers."
|
| I don't know anymore details than that. I don't know how valid this is
| as I don't see any mention of it at sco.com.

I've heard about this too.

| I have tested the TZ fix mentioned in this group, and it appeared to
| be great for the OS, not sure about some of our apps if they use TZ or
| do it themselves..

What would your applications do that wouldn't use values returned by the
kernel?

The kernel keeps time in seconds since the epoch (1/1/70 at midnight in
UTC). Inodes maintain files' mtime, ctime, and atime in the same way.
The TZ variable tells the kernel how to translate that number into what
is shown when you run commands like 'date' or 'ls -l'.

The SCO patches modify /usr/lib/libc.* so that it knows the US rules
about stop|start points for Daylight Saving Time. Then, the simple
short EST5EDT suffices: the longer form with the specific stop|start
points do not have to be specified. The libc.* routines maintain
knowledge not just of the 2007 rules, but of several generations of rule
changes that have occured since the epoch. However: this is true only
of North American timezones.

Aside from using a more compact TZ string, this means that the correct
local time for OLDER timestamps can be reported correctly. IOW, if the
timestamp falls in a week which is EDT in 2007 but was EST before the
change to the law, you can get it properly reported. But please name me
a case where it matters to know that a prior-year file's last-modified
time was at 14:03:45 rather than 13:03:45?