Begin Tab Sub Links

Daylight Saving Time (DST) FAQ

last updated on: 2007-12-09
General
  1. Why does timezone data change?
  2. Where does one find information about timezones world-wide?
  3. Why do I need to care about timezone data?
  4. Is there an complete emergency backout procedure should we notice an application dependency or the DST mandate be repealed?
  5. I run my global systems on GMT. Are they "safe" if I do not apply the patches?
  6. Bermuda has just announced they will follow the US in regards to DST. What action is Sun taking?
  7. Venezuela has recently announced they are changing their timezone. What action is Sun taking?
  8. If I have a Sun One mail server in Memphis that Venezuela users access via their PCs (either through the Web or through an IMAP client), does the workaround need to be applied to the server in Memphis?
Solaris
  1. Could you confirm that a system re-boot is required after Solaris 8, 9 & 10 DST patches are applied? It looks like they can be performed online with IBM systems.
  2. The zoneinfo patch is just an update of regular files. So why do we need to reboot?
  3. What is POSIX TZ and what is Olson? How can I tell?
  4. I don't know if I use POSIX, and I want to install POSIX DST patch on my systems to cover all bases. Are there any risks with this approach?
  5. Can any servers using a timezone other than a US timezone be affected by these changes? e.g. GMT or BST?
  6. If a server is using a non-US TZ, should the patches for Sun Alert 102775 be applied?
  7. Is there any specific code in the DST patches which would directly or indirectly affect other timezone rules such as GMT?
  8. If a server in the UK, executes a transaction which includes the current time in New York, does not have the US DST patch installed, is it possible that that the application would make an error since the US DST rules were not patched?
  9. We have mixed zone configurations. Some of them are set up using sparse root file system, the others are whole root file system for the zones. Are there any different procedures to patching them? What's the recommended way in this situation?
  10. Are there any patch dependencies to consider prior to installing the DST patches for Solaris?
  11. Can I just use one of the public domain solutions or a solution available from a third party to address the DST time issue on my Solaris system?
  12. If my client systems use an NTP server, do I need to mitigate these systems as per the DST recommendations?
  13. We have NTP set up on our Sun boxes and someone told us we need to patch the sun servers to handle this. If we are using SUN's xntpd daemon, is there a problem with the DST change?
  14. Does the zdump command output reflect changes made to the OS via the timezone and libc patches?
Java SE
  1. We are OS system administrators and are unfamiliar with Java. How do we determine if we are compliant with the new DST standards?
  2. If we only apply firmware and OS patches and do not use JAVA are we ok?
  3. Do all versions of Java require some sort of repair for DST?
  4. Why is the Java eol version 1.2.2 distributed on a non eol Solaris 8 Install CD?
  5. Do we need to reboot after the Java DST fixes are applied?
  6. I am facing a scenario which involves us forcibly rebooting upto 50000 workstations after the application of TZ Update to our JREs. This is due to the fact that the JRE must not be in use during the update. How can I mitigate this issue?
  7. How do I report a problem with the tzupdater tool?
  8. Is there a way to regress a tzupdater tool update?
  9. Sun's tzupdater tool makes reference to 1.4.2_11 being the first release to have US DST2007 changes included. However, we know that the Canadian timezones didn't get included until 1.4.2_13. We have a few instances of 1.4.2_11 that we'd prefer to use Sun's tzupdater tool to patch rather than upgrading to 1.4.2_13. Can Sun please confirm that running their current tzupdater against 1.4.2_11 will be have the desired outcome?
  10. Is a tzupdater tool available for JREs prior to release 1.3.19?
  11. What are the support guidelines around the priority and response times to the Java DST issue for those exceptions where a un-patched JRE is run and fails in production?
  12. What is the level of the Olson Database are included in tzupdater tool. Is it up to tz2007a? If not, is there a new release of tzupdater tool in the works?
Java in Solaris
  1. Why do I need to worry about Java in Solaris?
  2. What OS patch levels were used to certify each version of Java? We need to know this to verify our systems are compliant after the new DST upgrades.
  3. Do I need to remove Java 1.1 since it is EOL?
  4. Does Solaris 9 have dependencies on Java 1.2.2?

  5. See also here.
Other Software
  1. Why will SMC not restart after Java DST patches are applied to Solaris 8?
  2. I am still using the Rogue Wave libraries delivered with WorkShop 5.0. Will there be patches to update the DST problems within Rogue Wave for WorkShop 5.0?
Systems
  1. Are their any temporary workarounds for the DST change on Sun Fire systems. I will be unable to implement the necessary firmware upgrades on 5 of my Sun Fire 6900's by March and I am looking for a temporary workaround such as disabling the clock sync between the system controllers and domains and then manually changing the times on all of their domains?



General

Q. Why does timezone data change?
  • Timezone settings are locally adopted.
    • There is no world timezone authority.
    • In North America, timezone adoption can occur at the state/province, county or city.
    • There are a wide variety of local concerns which can drive a municipality to alter their timezone:
      • large events (e.g. the Commonwealth Games in Sydney),
      • voting (e.g. Brazil altered their setting for national elections one year),

Q. Where does one find information about timezones world-wide?
Q. Why do I need to care about timezone data?
  • Timezone data changes frequently.
    • This is reflected in the rate of change to the Olson database. The US-DST changes for 2007 just happen to be one of the changes impacting North American residents and customers.

Q. Is there an complete emergency backout procedure should we notice an application dependency or the DST mandate be repealed?
  • No. In general check with the DST website before proceeding along this path. Remember, DST is a regional activity. It may be repealed in one country and not another. Reapplication with updated Olson data will be necessary.

Q. I run my global systems on GMT. Are they "safe" if I do not apply the patches?
  • If all of the applications running on the system use only GMT, and will *never* perform local time conversion to other timezones, the system will not be impacted.
  • Note: All systems and all data need to be running on GMT to avoid DST issues. Patched systems and unpatched systems will disagree with each other about the tranlations between affected timezones and GMT

Q. Bermuda has just announced they will follow the US in regards to DST. What action is Sun taking?
  • These changes are listed on the Olson 2007a data. This will require another revision of the timezone patches. A workaround is to set your timezone to US Eastern Time.

Q. Venezuela has recently announced they are changing their timezone. What action is Sun taking?
  • Sun is working on official patches, in the meantime Sun has developed workarounds for Solaris, Java, etc. Sun customers in Venezuela seeking assistance to deal with this event should contact Sun Venezuela Support Services at +58-212-9053888. For customers outside of Venezuela please contact your local Sun support organization.

Q. If I have a Sun One mail server in Memphis that Venezuela users access via their PCs (either through the Web or through an IMAP client), does the workaround need to be applied to the server in Memphis?
  • No, the workaround does not need to be applied to the server in Memphis. The Venezuelan clients are responsible for keeping track of their local system time, with the assumption that the Web/IMAP servers running on system in Memphis do not use Venezuela timezone. You only need the workaround(s) if your environment is running on Venezuela time.




Solaris

Q. Could you confirm that a system re-boot is required after Solaris 8, 9 & 10 DST patches are applied? It looks like they can be performed online with IBM systems.
  • Yes - the timezone patches clearly state that a reboot is required. There are two patches, one for libc and and one for zoneinfo.
  • The zoneinfo database is loaded into the process. The information will not be reloaded until TZ environment variable is changed or process is restarted. In order to ensure that all processes which have loaded the zoneinfo database, reload the new zoneinfo database, is system reboot is required.
  • A reboot is always required for the libc patches to maintain system integrity.

Q. The zoneinfo patch is just an update of regular files. So why do we need to reboot?
  • Reboot is the only way to ensure that all applications running on the systems reread zoneinfo files. Zoneinfo database is once read in processes/applications and is never reread. The only way to let them reread new zoneinfo files is to restart the application/processes.

Q. What is POSIX TZ and what is Olson? How can I tell?
  • There are two types of TZ variable setting supported in Solaris. One is so called POSIX timezone, and the other is called Olson.
  • POSIX TZ has a form of "std offset dst offset" (eg PST8PDT) which TZ string itself represents timezone abbreviation and offset from UTC. It "dst offset" was given, US DST rules are used. The default US rules are hardcoded in libc. Therefore, it you are using this form, they need libc patches.
  • The other form of TZ variable (Olson) is of the form "US/Pacific", which points to the file under /usr/share/lib/zoneinfo and each file contains timezone definitions. There are a lot of files under the directory for many regions. If you are using this form, you need zoneinfo patches.
  • See man page of environ(5).

Q. I don't know if I use POSIX, and I want to install POSIX DST patch on my systems to cover all bases. Are there any risks with this approach?
  • No. In general, there are no risks with installing the POSIX patches. However some systems, such as those in Mexico, where the timezone was common with the US but which will continue to follow the old dates for DST in 2007, should not use the new POSIX times zones delivered in these libc patches. If such systems install these libc patches they should no longer use the POSIX style timezone. They would need to use Olson timezones only.

Q. Can any servers using a timezone other than a US timezone be affected by these changes?
  • Refer to the description of bugs listed in patches to verify if there is any update in the timezones. If applications running on the servers use only TZ=GMT or TZ=BST, and will *never* perform local time conversion to other timezones, there is no impact.

Q. If a server is using a non-US TZ, should the patches for Sun Alert 102775 be applied?
  • See the description of bugs listed in patches if there is any update in their timezones. If there are changes in your timezone, and if that is critical for you the patches need to be installed.

Q. Is there any specific code in the DST patches which would directly or indirectly affect other timezone rules such as GMT?
  • Refer to the descriptions of all bug numbers listed in the patches. There may or may not be changes in your timezones. However, if applications on your system use only "TZ=GMT" (POSIX time zone setting which doesn't observe DST), and would *never* perform local time conversion to other timezones, you will not be impacted.

Q. If a server in the UK, executes a transaction which includes the current time in New York, does not have the US DST patch installed, is it possible that that the application would make an error since the US DST rules were not patched?
  • US TZ rule will be used when you convert local clock in New York to UTC or GMT or whaterver outside of the zone. If your servers in UK don't have the patches and go to convert local clock in NY to UTC or local time in GMT, it will NOT be done correctly during March 11th - April 1st period if servers don't have patches.

Q. We have mixed zone configurations. Some of them are set up using sparse root file system, the others are whole root file system for the zones. Are there any different procedures to patching them? What's the recommended way in this situation?
  • These patches are like any other patches for Solaris 10. The patching script should take care of the zones in the system.

Q. Are there any patch dependencies to consider prior to installing the DST patches for Solaris?
  • Please refer to the "Patches required with this patch:" section in each patch README. This will provide the details on whether any additional patches are required prior to installing the DST patches.

Q. Can I just use one of the public domain solutions or a solution available from a third party to address the DST time issue on my Solaris system?
  • Sun knows Solaris best, and has developed, tested and released authentic patches to address the DST time issue. Sun does not consider public domain or third party solutions to be comprehensive, and these solutions are not supported by Sun. Use of these unsupported solutions is at your own risk, and can ultimately do damage to your system or disrupt your data. In order to have a tested and supported solution, you should install and use the Sun provided patches.

Q. If my client systems use an NTP server, do I need to mitigate these systems as per the DST recommendations?
  • The NTP server provides the time in UTC (GMT) seconds, since January 1, 1900, and the client systems convert to whichever timezone has been set. The NTP server only keeps the kernel time correct. You will need to install the applicable DST patches on the clients as they manage their own timezone information.

Q. We have NTP set up on our Sun boxes and someone told us we need to patch the sun servers to handle this. If we are using SUN's xntpd daemon, is there a problem with the DST change?
  • Yes, even when running xntpd you still need to patch all your system. NTP has no notion of timezones so will not help in any way with the DST changes.

Q. Does the zdump command output reflect changes made to the OS via the timezone and libc patches?
  • Yes it does reflect that the patches are installed. Results after successfully applying the patches should look like:

    >zdump -v US/Eastern | grep 2007
    US/Eastern Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isdst=0
    US/Eastern Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isdst=1
    US/Eastern Sun Nov 4 05:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 EDT isdst=1
    US/Eastern Sun Nov 4 06:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 EST isdst=0



Java SE

Q. We are OS system administrators and are unfamiliar with Java. How do we determine if we are compliant with the new DST standards?
Q. If we only apply firmware and OS patches and do not use JAVA are we ok?
  • Not likely. Many third party applications use Java. You may end up with a correct system time and incorrect application time.

Q. Do all versions of Java require some sort of repair for DST.
  • No. However, changes are constantly being made to the Olson data (geographic time change database). See the Java information.

Q. Why is the Java eol version 1.2.2 distributed on a non eol Solaris 8 Install CD.
  • For compatibility reasons because Solaris has utilities within which depend on 1.2.2

Q. Do we need to reboot after the Java DST fixes are applied?
  • No, but all Java applications which reference it should be stopped and restarted.

Q. I am facing a scenario which involves us forcibly rebooting upto 50000 workstations after the application of TZ Update to our JREs. This is due to the fact that the JRE must not be in use during the update. How can I mitigate this issue?
  • A reboot is not required. However, the application must be restarted to prevent data corruption. If there was any use of dates and times going on there is the possibility of that now changing depending on the date and time. They would then have a form of data corruption if they did not restart the application after the update so our recommendation is to restart the application.
    1. Stop the application
    2. Mitigate (update release install or use the tzupdater tool)
    3. Restart the application
    4. Test as needed. (Optional)

How do I report a problem with the tzupdater tool?
  • If you find issues with the tzupdater tool you should log a Sun support call.

Q. Is there a way to regress a tzupdater tool update.
Q. Sun's tzupdater tool makes reference to 1.4.2_11 being the first release to have US DST2007 changes included. However, we know that the Canadian timezones didn't get included until 1.4.2_13. We have a few instances of 1.4.2_11 that we'd prefer to use Sun's tzupdater tool to patch rather than upgrading to 1.4.2_13. Can Sun please confirm that running their current tzupdater against 1.4.2_11 will be have the desired outcome, in that it will apply a proper TZ database with the updated DST2007 Canadian timezones? We want to confirm that the tzupdater tool won't make a US-biased decision and not patch 1.4.2_11 & above because this is already deemed "DST2007 compliant" from a US perspective.
  • The tzupdater tool has Olsen data 2006p (it's cumulative over time) and as such it contains the changes needed for Canada. To avoid the need of applying the v1.4.2_13 update they can use the tzupdater tool and get the desired results. ie. DST 2007 for Canada.

Q. Is a tzupdater tool available for JREs prior to release 1.3.19?
Q. What are the support guidelines around the priority and response times to the Java DST issue for those exceptions where a un-patched JRE is run and fails in production.
  • For issues with (or after) the DST mitigations then a Sun support case will need to be logged. Response times will be in line with your Sun support contract.

Q. What is the level of the Olson Database are included in tzupdater tool. Is it up to tz2007a? If not, is there a new release of tzupdater tool in the works?
  • Currently it is 2006p
  • A revision for 2007a (only change being the Bahamas, relative to USA-2007-DST) is in development



Java in Solaris

Q. Why do I need to worry about Java in Solaris?
  • There are a number of products in Solaris that are Java based and require the version(s) for Java being used to be updated.

Q. What Solaris patch levels were used to certify each version of Java? We need to know this to verify our systems are compliant after the new DST upgrades.
  • Sun does not maintain a Java/OS patch dependency matrix. There has been no instances where a Java DST update was applied that caused subsequent Java errors.

Q. Do I need to remove Java 1.1 since it is EOL?
  • No, but removal of 1.1 would ensure developer could not access it to produce non compliant code.

Q. Does Solaris 9 have dependencies on Java 1.2.2?
  • No, there are no Solaris 9 dependencies on Java 1.2.2 and it may be removed. However, there may be applications which are using Java 1.2.2. Customers should update to the minimum level of Java.



Other Software

Q. Why will SMC not restart after Java DST patches are applied to Solaris 8?
  • This is currently under investigation.

Q. I am still using the Rogue Wave libraries delivered with WorkShop 5.0. Will there be patches to update the DST problems within Rogue Wave for WorkShop 5.0?
  • Workshop 5.0 reached the End of Service Life (EOSL) in 2005. Customers using this product will need to upgrade to newer compilers. The OS will also need to upgraded. Workshop 5 was supported on Solaris 2.5.1, 2.6 and 2.7, all of which have reached EOSL. Upgrading to Studio 11 (C++ 5.8) will, by default, generate compatible code. All Sun C++ compilers from Workshop 5.0 (C++ 5.0) through Studio 12 Early Access (C++ 5.9) default to -compat=5, and generate compatible object code. Binaries generated by an older C++ 5.x compilers can be linked into a program created by a later C++ 5.x compiler. For example: If you have an old library created by Workshop 5, and you have upgraded to Sun Studio 11. You can continue to link the old library into programs created by Sun Studio 11.



Systems

Q. Are their any temporary workarounds for the DST change on Sun Fire systems. I will be unable to implement the necessary firmware upgrades on 5 of my Sun Fire 6900's by March and I am looking for a temporary workaround such as disabling the clock sync between the system controllers and domains and then manually changing the times on all of their domains?
  • Switch to using a GMT offset. It does not adjust for daylight saving time. Below is an example...

    tpa-sf4800a-sc0:SC> setdate -t -h
  • This will give a list of valid GMT offsets for the various timezones - I'm EST so to set it:

    tpa-sf4800a-sc0:SC> setdate -t GMT-05:00
    Thu Jan 18 10:05:15 GMT-05:00 2007
    tpa-sf4800a-sc0:SC>
  • On the spare, disable failover, run the command and re-enable failover. You cannot run the command on the spare with failover enabled/active.




Change Log

Note: This Change Log only reflects changes made to this web page. Please refer to product specific information for details of product updates.
  • [2008-08-22] Removed outdated questions from the Solaris section.
  • [2007-12-09] Added questions #7 and #8 to General section.
  • [2007-02-26] Added information for Java 1.3.1 tzupdater tool.
  • [2007-02-23] Added Question #24 to Solaris questions.
  • [2007-02-23] Added link to Java SE SDN FAQ.
  • [2007-02-16] Added Question #2 to Other Software.
  • [2007-02-14] Added Question #22 to Solaris questions.
  • [2007-02-12] Added clarifying text to GMT related questions.
  • [2007-02-08] Edited Question #3 in Solaris questions.
  • [2007-02-08] Added Question #4 to Solaris questions.