SUMMARY: Question about timezone daylight saving changes in Tru64

From: Roberto Mackun (Roberto.Mackun@poports.com.au)
Date: Thu Feb 16 2006 - 16:43:03 EST


Thanks to Dr. Thomas Blinn and Johan Brusche for their responses.

According to Dr. Thomas Blinn:
***************************************
Sun may have figured out a way to cache the data. As far as I know, Tru64
UNIX does not do so, the library code that deals with external formatted
representation of time retrieves the values needed "on the fly" each time.
Of course, if the relevant file remains open in the process and the data is
mapped in memory, the code might retrieve stale data, but once the data is
changed on disk, any new reference will find the new data. So the question
comes down to whether the library manages to keep the file open, and as far
as I recall, it does not do so.

Of course, rebooting from time to time provides a clean slate, other than
the disruption to running processes.
***************************************

According to Johan Brusche:
***************************************
Correctly written applications use the UTC-time as reference and
when running ntp with a good NTPserver (not a Windows semi-ntp server),
the systems internal UTC reference will be very close to that.

The /etc/zoneinfo/localtime, only provides a human readable and
localized "representation" of that UTC.
Applications that store this localized representation in their data
records are badly designed.

So if you create a new zic, just make sure that the localtime link
points
to that new file.
****************************************

Thank you.

Regards,
Bobby

> -----Original Message-----
> From: Roberto Mackun
> Sent: Thursday, 16 February 2006 12:32 PM
> To: tru64-unix-managers@ornl.gov
> Subject: Question about timezone daylight saving changes in Tru64
>
> Greetings Managers,
>
> According to a SUN article, there is a recommendation to reboot servers
> after applying DST (daylight savings time) changes to the timezone data
> (excerpt shown below). SUN seems to suggest that timezone data are only
> read by processes when they start. I haven't found any documents which
> mentions that a reboot would be necessary after compiling new timezone
> files with zic(8) for Tru64.
>
> Does anybody have any information whether a reboot would be necessary?
>
> Regards,
> Bobby
>
> Excerpt from SUN recommendations for DST changes in Solaris:
> <<snip>>
> NOTE: The changes below may appear to take effect immediately, BUT, any
> processes already running on the system(including daemons such as cron,
> syslogd, etc) will cache the outdated timezone data until they are
> restarted. Due to the difficulty in determining which processes must be
> restarted, re-booting the entire system is the preferred and recommended
> option.
> <<snip>>

*************************************************************************************************
"This e-mail and its attachments are intended for the named addressee only and no liability is accepted for use or reliance on any part of this e-mail by any other person. It is confidential, may be subject to privilege and is also subject to copyright. No part of it should be reproduced, adapted or communicated without the written consent of the copyright owner. Any confidentiality or privilege is not waived or lost because this e-mail has been received by you and you are not the intended recipient. If you are not the intended recipient, please let us know by reply e-mail.

Please note that e-mails can be interfered with, can contain computer viruses or other defects and may not be successfully replicated on other systems. This footnote confirms that this e-mail message has been swept for the presence of computer viruses. However whilst the sender has taken reasonable precautions to minimise the risk of this email and any attachment containing viruses, we cannot accept liability for any such viruses and we give no warranties in relation to any of the above matters. If you have any doubts about the authenticity of this e-mail please contact the sender immediately. No responsibility is accepted for any changes made to a document other than those made by the sender."



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:50:28 EDT