Daylight Savings Changes 2007

Daylight Savings time will be altered in 2007 as seen in http://geography.about.com/cs/daylightsavings/a/dst.htm
Is Coherence certified to handle these changes? We have already found issues in the OS and JDK that need to be patched.

Coherence will correctly handle daylight savings changes once the JDK has been patched.
Without the JDK patch, only the Coherence logging function will be incorrect, in that the logged messages will reflect the incorrect (unpatched) "timezone".
Coherence has very careful handling of "wall clock time" functionality to avoid being impacted by network time daemons, system clock irregularities, time zone shifts, etc.
Peace,
Cameron Purdy
Tangosol Coherence: Data Grid and Clustered Cache

Similar Messages

  • 2007 US Daylight Savings change time zone support in JDK 1.3

    Sun has supported the 2007 US Daylight Savings change in recent versions of its JDKs 1.4 and 1.5. It has made partial Daylight Savings changes to JDK 1.3, but it's not a complete implementation like in 1.4 and 1.5, because there is no support for past/future Daylight Savings rules, only a single current set of Daylight Savings rules per time zone.
    Our Java application (running in the America/New_York time zone) seems to be doomed, because the likelihood of upgrading to JDK 1.4/1.5 seems slim (we have to upgrade a third-party product first and success is seeming more and more remote), and Sun claims to be unable to fully implement the Daylight Savings change in JDK 1.3.
    If any Sun Java staff can explain the reasons for being unable to implement the change in 1.3 (or at least some kind of workaround that an individual JVM user could enable), please fill me in. Any pointers on cleanly setting up a custom workaround would be valuable too.
    If there are other Java users in the same situation, please fill me in on your own plans if you can. Is anybody trying to pressure Sun or other vendors for a solution? Is anybody writing their own custom workaround?
    More details....
    What we really need is for the default TimeZone in JDK 1.3 (America/New_York on our machines) to work regardless of whether the date/time being checked is pre-2007 or post-2007. In particular, getOffset and inDaylightTime should work for both 2006 dates and 2007 dates. The JDK should return the correct values for 2006 dates, as well as the correct values for the 2007 US DST extension dates (03/12/2007-04/02/2007 and 10/29/2007-11/05/2007). This would enable parsing and formatting using SimpleDateFormat to work correctly as well. The TimeZone and SimpleDateFormat APIs are used throughout our application.
    JDK 1.3.1_19 has an interesting workaround that depends on the current system time. Prior to Jan 1 2007, it will handle 2006 dates correctly but 2007 dates wrong. After Jan 1 2007, it will handle 2007 dates correctly but 2006 dates wrong. Either way, it is always wrong for some dates.
    JDK 1.4.2_13 and 1.5.0_09 both handle 2006 and 2007 dates correctly.
    If JDK 1.3 will never work for 2006 and 2007 dates, then I am contemplating two workarounds:
    1. Set the default TimeZone to a custom implementation as soon after JVM startup as possible.
    2. Avoid the default TimeZone entirely, changing our application code to rely on explicit custom TimeZones.
    Prior related Java Forum topics:
    * http://forum.java.sun.com/thread.jspa?forumID=31&threadID=645874 (Java Essentials - Java Programming) winds up referencing the JDK 1.4 patch as a solution, and there is some discussion about how future/historic dates affect applications
    * http://forum.java.sun.com/thread.jspa?forumID=481&threadID=735038 (Deploying - Java Upgrade) just talks about 1.4 and 1.5 patches
    * http://forum.java.sun.com/thread.jspa?forumID=481&threadID=717268 (Deploying - Java Upgrade) also just talks about 1.4 and 1.5 patches
    * http://forum.java.sun.com/thread.jspa?forumID=37&threadID=703214 (Specifications - Java Virtual Machine (JVM)) also just talks about 1.4 and 1.5
    Related Sun Java Bug Database bugs:
    * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6471271 reports the same issue with 1.3.1_19 that I am seeing and the reporter makes the same clarification, that past/future dates don't work at all still. Sun seems to indicate that it will not fix this in 1.3.1, and the 1.3.1_19 "hack" is it for 1.3.1.
    * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6391777 refers to updates in 1.3.1_18 to address Australia DST changes, and also indicates that past/future dates (or "historic" dates) won't work at all. It gives a little more rationale behind the difficulty of implementing this for 1.3.1.
    * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4257314 refers to the fixes in 1.4 to support historic DST dates.
    Other articles:
    * Sun Java article http://java.sun.com/developer/technicalArticles/Intl/USDST/ refers to 1.3.1_18 as "resolving" the DST issue - this is misleading because the solution in 1.3.1_18 is not complete like that in 1.4 or 1.5
    * Server Side article http://www.theserverside.com/news/thread.tss?thread_id=42212 refers to fixes in 1.4 and 1.5 for the DST issue, and the discussion about 1.3 doesn't lead anywhere
    Thanks for any info or advice available,
    Jim

    Hi KBarney
    I think u have the correct data file. to make sure see the "zi" dir is backed up in ur java lib folder or not.
    if u have suspicion than run the tzupdater tool again.
    this tool must be run for each jre/java version on your machine separately.
    I tried this on 1.4.2.13 and not on 1.5.0.10. here is the result:
    C:\Program Files\Java\j2re1.4.2_13\bin>java -jar c:\tzupdater\tzupdater2006p\tzu
    pdater.jar -t -v
    java.home: C:\Program Files\Java\j2re1.4.2_13
    java.vendor: Sun Microsystems Inc.
    java.version: 1.4.2_13
    JRE time zone data version: tzdata2006p
    Embedded time zone data version: tzdata2006p
    Validating the time zone data
    Validation complete
    C:\tzupdater\tzupdater2006p>java -jar tzupdater.jar test verbose
    java.home: C:\Program Files\Java\jre1.5.0_10
    java.vendor: Sun Microsystems Inc.
    java.version: 1.5.0_10
    JRE time zone data version: tzdata2006k
    Embedded time zone data version: tzdata2006p
    Validating the time zone data
    /data/tzdata2006p.test:990: test failed: America/Managua
    /data/tzdata2006p.test:1465: test failed: America/Havana
    /data/tzdata2006p.test:1466: test failed: America/Havana
    /data/tzdata2006p.test:1847: test failed: Cuba
    /data/tzdata2006p.test:1848: test failed: Cuba
    /data/tzdata2006p.test:2024: test failed: America/Campo_Grande
    /data/tzdata2006p.test:2026: test failed: America/Campo_Grande
    /data/tzdata2006p.test:2028: test failed: America/Campo_Grande
    /data/tzdata2006p.test:2030: test failed: America/Campo_Grande
    /data/tzdata2006p.test:2032: test failed: America/Campo_Grande
    /data/tzdata2006p.test:2034: test failed: America/Campo_Grande
    /data/tzdata2006p.test:2036: test failed: America/Campo_Grande
    /data/tzdata2006p.test:2038: test failed: America/Campo_Grande
    /data/tzdata2006p.test:2040: test failed: America/Campo_Grande
    /data/tzdata2006p.test:2046: test failed: America/Cuiaba
    /data/tzdata2006p.test:2048: test failed: America/Cuiaba
    /data/tzdata2006p.test:2050: test failed: America/Cuiaba
    /data/tzdata2006p.test:2052: test failed: America/Cuiaba
    /data/tzdata2006p.test:2054: test failed: America/Cuiaba
    /data/tzdata2006p.test:2056: test failed: America/Cuiaba
    /data/tzdata2006p.test:2058: test failed: America/Cuiaba
    /data/tzdata2006p.test:2060: test failed: America/Cuiaba
    /data/tzdata2006p.test:2062: test failed: America/Cuiaba
    /data/tzdata2006p.test:2471: test failed: America/Montevideo
    /data/tzdata2006p.test:2472: test failed: America/Montevideo
    /data/tzdata2006p.test:2475: test failed: America/Montevideo
    /data/tzdata2006p.test:2476: test failed: America/Montevideo
    /data/tzdata2006p.test:2479: test failed: America/Montevideo
    /data/tzdata2006p.test:2480: test failed: America/Montevideo
    /data/tzdata2006p.test:2483: test failed: America/Montevideo
    /data/tzdata2006p.test:2484: test failed: America/Montevideo
    /data/tzdata2006p.test:2487: test failed: America/Montevideo
    /data/tzdata2006p.test:2494: test failed: America/Sao_Paulo
    /data/tzdata2006p.test:2496: test failed: America/Sao_Paulo
    /data/tzdata2006p.test:2498: test failed: America/Sao_Paulo
    /data/tzdata2006p.test:2500: test failed: America/Sao_Paulo
    /data/tzdata2006p.test:2502: test failed: America/Sao_Paulo
    /data/tzdata2006p.test:2504: test failed: America/Sao_Paulo
    /data/tzdata2006p.test:2506: test failed: America/Sao_Paulo
    /data/tzdata2006p.test:2508: test failed: America/Sao_Paulo
    /data/tzdata2006p.test:2510: test failed: America/Sao_Paulo
    /data/tzdata2006p.test:2516: test failed: BET
    /data/tzdata2006p.test:2518: test failed: BET
    /data/tzdata2006p.test:2520: test failed: BET
    /data/tzdata2006p.test:2522: test failed: BET
    /data/tzdata2006p.test:2524: test failed: BET
    /data/tzdata2006p.test:2526: test failed: BET
    /data/tzdata2006p.test:2528: test failed: BET
    /data/tzdata2006p.test:2530: test failed: BET
    /data/tzdata2006p.test:2532: test failed: BET
    /data/tzdata2006p.test:2537: test failed: Brazil/East
    /data/tzdata2006p.test:2539: test failed: Brazil/East
    /data/tzdata2006p.test:2541: test failed: Brazil/East
    /data/tzdata2006p.test:2543: test failed: Brazil/East
    /data/tzdata2006p.test:2545: test failed: Brazil/East
    /data/tzdata2006p.test:2547: test failed: Brazil/East
    /data/tzdata2006p.test:2549: test failed: Brazil/East
    /data/tzdata2006p.test:2551: test failed: Brazil/East
    /data/tzdata2006p.test:2553: test failed: Brazil/East
    /data/tzdata2006p.test:3451: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3452: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3453: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3454: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3455: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3456: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3457: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3458: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3459: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3460: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3461: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3462: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3463: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3464: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3465: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3466: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3467: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3468: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3469: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3470: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3471: time zone not found: Europe/Podgorica
    /data/tzdata2006p.test:3791: test failed: ART
    /data/tzdata2006p.test:3814: test failed: Africa/Cairo
    /data/tzdata2006p.test:3844: test failed: Asia/Amman
    /data/tzdata2006p.test:3848: test failed: Asia/Amman
    /data/tzdata2006p.test:3852: test failed: Asia/Amman
    /data/tzdata2006p.test:3856: test failed: Asia/Amman
    /data/tzdata2006p.test:3860: test failed: Asia/Amman
    /data/tzdata2006p.test:3887: test failed: Asia/Damascus
    /data/tzdata2006p.test:3908: test failed: Asia/Gaza
    /data/tzdata2006p.test:3911: test failed: Asia/Gaza
    /data/tzdata2006p.test:3915: test failed: Asia/Gaza
    /data/tzdata2006p.test:3919: test failed: Asia/Gaza
    /data/tzdata2006p.test:3923: test failed: Asia/Gaza
    /data/tzdata2006p.test:4035: test failed: Egypt
    /data/tzdata2006p.test:4901: test failed: Australia/Perth
    /data/tzdata2006p.test:4902: test failed: Australia/Perth
    /data/tzdata2006p.test:4905: test failed: Australia/Perth
    /data/tzdata2006p.test:4906: test failed: Australia/Perth
    /data/tzdata2006p.test:4909: test failed: Australia/Perth
    /data/tzdata2006p.test:4910: test failed: Australia/Perth
    /data/tzdata2006p.test:4914: test failed: Australia/West
    /data/tzdata2006p.test:4915: test failed: Australia/West
    /data/tzdata2006p.test:4918: test failed: Australia/West
    /data/tzdata2006p.test:4919: test failed: Australia/West
    /data/tzdata2006p.test:4922: test failed: Australia/West
    /data/tzdata2006p.test:4923: test failed: Australia/West
    Validation tests failed.
    -Ranjan

  • Any imapct on MS JVM due to Daylight savings changes in 2007

    Is there any imapct on MS JVM due to the Daylight savings changes in 2007.

    I don't know. What did Microsoft support tell you when you asked them?

  • Daylight Savings Time -2007

    In 2007 when the US changes the start/end dates for daylight savings time, will Apple patch 10.4.x, 10.3.x etc?

    Apple has already patched Mac OS X 10.4 for the changes; this is included in Mac OS X 10.45 and newer.
    (17177)

  • Issue with All Day events - post Australian Daylight Savings change.

    Hi all,
    I have had a weird problem occur since daylight savings has changed for Australia.
    I sync my Microsoft Outlook 2003 on my PC and calender on my iPhone. This works great and I have never had a problem until now. Since Sunday, 'all day' events created on Outlook are going into the previous day on the iPhone, and any 'all day' events created on the iPhone are spread across two days on Outlook.
    All the timezones and clocks are correct on both devices and any specifc time appointments are correct on both devices. This only applies to All Day Events.
    The other strange thing is that it only occurs for days between now and the last weekend in October. Interestingly enough this was the old date of daylight savings changeover before it was brought forward in 2007.
    I think what is happening is that the iPhone's timezone doesn't know that it is daylights savings yet, even though the cell network is updating the clocks and making it appear correct.
    This is also happening to my colleague.
    Not sure how to fix this. Surely this is happening to others.
    Any help would be great...
    Trent

    i noticed with a client and outlook, when syncing with m.me i had a similar problem where i made an all day event and vs 1 day it was two.. the problem was tracked down to how outlook makes the event; it made a '24 hr event' not an 'untimed' event.
    I unchecked the 'all day even't and it showed the event going from midnight to midnight (which for no good reason it called that the next day which it is not).. I shortened up the duration to a few hours mid-day and then checked the 'all day' check and it made it one day again.
    post if it works.

  • Linked Files in InDesign Now Modified after Daylight Savings Change

    I looked for a discussion on this and couldn’t find one so if there is one already open please direct me to it and my apologies.
    I was wondering if anyone else has run into this problem after the Daylight Savings Time Change on November 6th.
    Starting on Monday, November 7th we have noticed that all of our InDesign files that had artwork files linked to the document are now coming up as being modified in the Links pallet even though that artwork has not been modified. I haven’t recalled having this issue since we were using Quark 4 and InDesign CS.
    All files are stored on Windows servers running ExtremeZIP, all InDesign files are being opened on Mac Intel and Mac PowerPc models running either OSX 10.4 or OSX 10.6. All servers and Macs are sinc’d to pull the date and time from the same server and we verified that they are matching to the second.
    We get the same results if the files are opened in InDesign CS4, CS5 or CS5.5.
    Is anyone else seeing this issue and if so have you been able to rectify it without updating all the links and saving the files.
    I’ve been searching everywhere and I have found tech notes from Adobe that states that this issue was fixed in CS4.0.6 but we are running this version and still suffering from the problem.
    Any help would be appreciated.

    This sounds like an ExtremeZIP bug. Like perhaps your server is not acconting for daylight saving properly in its on-the-wire protocol. I seem to recall there are a number of gotchas about this involving Windows. I would check with ExtremeZIP. Did the file dates/times change as shown by Get Info in the finder? I suppose it would be difficult to tell at this point...

  • Daylight Savings Time 2007 - firmware upgrade ?

    In 2007 the start and end dates are going to be different for Daylight Savings Time. As a result, servers are going to need to be patched. Here is a related link I came across:
    http://sunsolve.sun.com/search/document.do?assetkey=1-26-102617-1
    My question is, how do I know whether or not my firmware (PROM) needs to be updated too ? I have searched and have not found a lot of information on the topic of the firmware. Does anyone have any good links or pertinent information on whether the firmware would need to be updated or not ? I have several Netra T1's, Sunfire V480's, and my Sunblade 100 workstation that I am concerned about. Here is the OBP level from one of my V480's that is on Solaris 8: OBP 4.6.8 2002/09/04
    and here is the OBP from a V480 on Solaris 9: OBP 4.10.14 2003/11/19.
    Thanks for any information.

    The platforms mentioned in the Sun Alert 102617 that you linked above,
    are all Sun Fire Midrange Server systems.
    Their "firmware" is a part of a completely different sort of of architecture.
    Their system controllers are a tiny computer, with its own OS, inside the Sun Fire system.
    That Real Time Operating System (RTOS) that runs on the SC's has its own
    time-of-day function that is independant of whatever Solaris gets installed
    to whichever domain or domains you configure to the computer.
    Thus the need for the Sun Alert, separate from any TOD discussion for Solaris..

  • Daylight Saving Changes 2007

    Hi, I am using new_time() function in my code which takes timezone abbreviations like (PST, CST) to convet time from one timezone to other. As a part of DST changes in March 2007, do we also need to change this function to use abbreviations other than this?
    I tried doing this, but it returns an error.
    Can anybody help out...

    Have you gone through this doc in metalink? Doc ID:      Note:359145.1
    Subject:      Impact of 2007 USA daylight saving changes on the Oracle database

  • Alarm turned off after daylight savings change?

    Hi. I woke up late this morning. I know I set my alarm last night. Last night was the change to daylight savings (forward one hour). Ok, I'm human, so of course being asleep, I can't be 100% sure I didn't turn it off without waking... we all have done that right? :P But I'm fairly certain I didn't, and am wondering if this may be a software glitch. I don't want to wait 6 months to find out when it changes back.
    iPhone 4 fully updated. Alarm set to 5:30am

    It seems that because of the structure and communication of Apple corporation, the Apple telephone support staff may not necessarily know any more than a thoughtful user, and almost certainly will know less about this particular alarm issue than a user who peruses these forums. For example, they didn't know that turning off Time Zone Support is another way to temporarily solve the problem (as an alternative to changing Set Automatically to OFF) - something I learnt from an Apple discussion.
    This problem was raised in these discussions in June of this year for users in Lithuania and in Sri Lanka. It was New Zealand's turn in late September, and Australia's turn on Sunday. My guess is that Apple will scramble to fix the issue before it hits USA users in November, but why rush until then, when it's only users from other parts of the world (non-Americans) being affected?

  • Daylight savings change

    This weekend we moved into daylight savings. My calendar in my iPhone, running the latest patches, and my clendar on my PC are one our out.... Ids there a known problem here?
    Cheers
    John

    You need to apply microsoft daylight savings patch http://www.microsoft.com/downloads/details.aspx?FamilyId=81D03DA3-846C-4F7F-8791 -CD9943CE0893&displaylang=en. I had the same problem and now it works fine.

  • SAP systems and Daylight savings for 2007

    Hi,
    We are discussing about the Daylight Saving time changes in USA for 2007 and its effect on SAP Systems.
    <i>"Beginning in 2007, most of the U.S. will begin Daylight Saving Time at 2:00 a.m. on the second Sunday in March and revert to standard time on the first Sunday in November."</i>
    Wondering, if we need to change any variable settings to take into effect? If so, could anyone give details on it.
    Wondering if SAP systems time is getting sync with Database servers or O/S ?
    Thanks,
    Sam

    Hi,
    The beginning of daylight saving time is normally not a problem as the time will jump from 2:00 to 3:00, so seen from SAP that no problem. You will only have a 1 hour hole, as the system had nothing to do for one hour.
    So there are no settings or so to maintain or change. Just let SAP system run...
    But it is different when switching back to "normal" time, as there you will have the so called double hour, and even as SAP is working on a solution to this, it is still recommended to shut down the SAP system for this period.
    (searching for the term "daylight saving time" in OSS should give you some notes explaining how SAP is handling it)
    As i know SAP system is taking the time from OS, but you can se what time the SAP system has, by in the GUI menu to select the "system" => "Status"...
    (In the Popup you can se it in upper right corner)
    Regards
    Rolf

  • Will Business Connector 4.6 be affected by new  Daylight savings changes

    What are the implications for business connector 4.6, running java 1.3.1? does BC utilize the java timestamp function?

    Hi Rodney,
    this is the XI forum.
    I am not aware of any forums for Business Connector.
    The following  may help :
    use JRE 1.3.1_19,
    which fixes the daylight problem: see
    http://java.sun.com/developer/technicalArticles/Intl/USDST/
    #983147     Change of DST in USA and Canada 2007
    #1001092    Daylight Saving Time - Changes in 2007
    #309834     SAP BC release and support strategy

  • Citadel time wrong after daylight savings change

    I have just noticed that all of my previous alarms in Citadel are now
    off by 1 hour after the fall time change. For example, an alarm that
    occured at 4:00 am yesterday (and was in the Citadel database as 4:00
    am yesterday), is now shown as 3:00 am after the time change.
    Any work arond for this? I am running lookout 6.0
    Also, is there a way to change the order of the date field in Citadel?
    It displays as month first in the date colum. I would like YYYYMMDD
    HHMMSS so when I export to Excel it will sort corectly.
    Thanks in advance.

    alan,
    What Bob said is correct.  You can change the way Excel formats
    the date to however you want by right-clicking on the cells and
    selecting Format Cells..., then clicking on either Date, Time,
    or Custom, and changing the format that way, however this will have no
    bearing on how Excel sorts the columns.  The values are stored in
    Universal Time format.
    Doug M
    Applications Engineer
    National Instruments
    For those unfamiliar with NBC's The Office, my icon is NOT a picture of me

  • Daylight Savings Time 2007 and Jrockit JVM 1.4.2_04

    If I have applications running on WLS 8.1 SP2 with Jrockit JVM 1.4.2_04 on AS3, would the NEW Energy act of 2007 which resets the DST in march insteadt of April affect my JVM? If yes is there a patch?

    This fix is included in JRockit release R27.1 1.4.2_12 publically available from the download site.
    Read more: http://java.sun.com/developer/technicalArticles/Intl/USDST/
    BEA JRockit ports and includes the JDK from the Sun Java distribution, so things fixed in a Sun JDK is fixed in the corresponding BEA JDK.
    Kind regards, Cecilia
    BEA JRockit
    Kind regards,
    Cecilia Borg
    BEA WebLogic JRockit

  • Will daylight savings changes break OD if not done?

    I've got a client a few hundered miles away with a 10.3.9 open directory server. I'm not sure I can get over there to apply the DST patches before the time comes. Can this break OD authentication in some fashion if not done? Since the actual authentication is done internally against itself and the clients just use LDAP I would guess that it'd be OK? Logfiles will obviously be an hour old, but I can deal for the time being..
    Thanks!

    Is this server an OD master for other servers? If not, probably nothing will happen. If it IS a master for other servers, you'll want to apply the patch before any changes are made to the OD database (i.e. password changes, etc.).

Maybe you are looking for