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.
All versions of Solaris. Solaris 8, 9 and 10 have fixes available for all but the recent DST change announcement for The Bahamas. For information on earlier versions of Solaris, see older versions of Solaris.
The patch is free for Solaris 8, 9 and 10 customers with Sunsolve access. Customers with SunSpectrum service plans or Solaris service plans or subscriptions are eligible for the free patch and Engineering support provided that their OS version is 8, 9 or 10. Customers who run a Vintage Solaris version are eligible for a free patch if they subscribe to full engineering extension vintage support. These customers have already received the patch. A separate license agreement is required to be completed before receiving these patches.
All customers who do not have a custom full engineering support extension and run Solaris 2.5, 2.6 and 7 must pay for the patch. This includes customers with SunSpectrum service plans and Solaris service plans. Their contracts have clear terms about what versions of Solaris they have engineering support for and 2.5, 2.6 and 7 are no longer covered. Customers with custom phone support contracts for these versions who did not pay for engineering support are also required to pay for the patch. The terms of our post EOL Solaris support are all detailed here, and this program complies 100% with existing policy.
Customers who purchase the patches for more than $30,000 can receive a credit for Migration Services.
If you have purchased the Vintage Solaris Release DST patches for more than $30,000, and would like to consider upgrading your systems to Solaris 10, you are eligible to participate in a promotion for Migration Services.
The first step is to engage with Sun for the Enterprise Migration Justification Review Service. In this step, Sun works with you to scope your project, select the best upgrade strategy, and obtain order-of-magnitude estimates for overall project complexity and size. You can compare the benefits of migration against the constraints, helping you articulate a business case for the scope of the transformation. This service has an average list price of US $10,000.
If you decide to go ahead and upgrade your Solaris software, the second step is to engage with Sun for Architecture, Implementation or Application Migration Services. These services are custom priced.
The promotional offering allows you to get a credit, up to the total cost of the patches, and apply it toward the price for the Migration Services. For example, if you paid $50,000 for the DST patches, you could apply $10,000 towards the Enterprise Migration Justification Review and up to $40,000 for the follow-on Architecture and Implementation Services. If the total price for the Migration is $100,000, you would be responsible for the additional $50,000. If you are interested in this offer, please contact your Sun Sales Representative.
Note: The following rules apply. 1) customers must purchase the DST Patches for more than $30K USD, 2) credit for future Migration Services can only apply to the Sun Enterprise Migration Suite, which includes 5 different service offerings, 3) the services must be scheduled and delivered by June 30, 2007 for the credit to apply.
It is possible that other countries will adopt a new policy for Daylight Saving Time. At present, Sun supports those countries that have announced changes for 2007. If other countries also decide to make that change, then Sun will support those countries with a patch extension. Such an extension will be made available as part of the current purchase price and therefore no additional cost will be incurred by customers in the future.
Sun customers form a strong community and for System Administrators, the BigAdmin public site is well visited. Therefore, all Daylight Saving Time patch policies and guidance is posted to BigAdmin at: http://www.sun.com/bigadmin/hubs/dst/
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.
The patches are currently available, but you need to contact your support center and open a T&M Case. Once the T&M case has been approved and you have signed the corresponding license agreement, the patches will either be FTPed or emailed to you.
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.
When testing the time roll forward/back using Solaris OS-level commands, the time will spring forward from March 11th, 2007 2:00 AM EST to March 11th, 2007 3:00 AM EDT (correct behavior in both springing forward 1 hour AND changing from EST to EDT).
Now, with the time set to EDT, we change the date/time to November 4th, 2007 1:59AM - however, it also changes the time setting from EDT to EST. Thus, when 2:00AM arrives, the system sees that it is already EST (not EDT) and therefore does not fall back to 1:00 AM. If you were to change the time to something before 1:00AM (e.g. November 4th, 2007 12:59AM), it would maintain the EDT setting and thus correctly fall back an hour at 2:00AM to November 4th, 2007 1:00AM EST.
Why? As you can arrive at 1:00 twice on the day of EDT-to-EST roll back (the first time you pass it and then when you fall back to it), the Solaris command level date/time command does not know which is correct and just uses the default of EST. Therefore, when testing the November roll back, the time must always be changed to something before November 4th 1:00AM.
The patches have been thoroughly tested to work correctly.
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
