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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
Stop the application
Mitigate (update release install or use the tzupdater tool)
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.
A tzupdater tool for 1.3.1 is available to customers who have subscribed to a Sun support contract. See http://sunsolve.sun.com/search/document.do?assetkey=1-9-88428-1. The version of tzupdater for JDK/JRE version 1.3.1 supports Windows platforms and the Solaris operating system.
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.
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.
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.
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.
Print-friendly Version
