Daylight savings bug

I had this wierd problem last night.  I have a scheduled sleep at midnight every night.  However, due to daylight savings time between midnight and 1 am, I was unable to dismiss the dialogue and could not use my computer regardless of log in/ restarting.  I was unable to dismiss the 'cancel' dialogue.

I can confirm the exact same problem. My sleep time was set to 1am. From 1am to 1:30am I could not dismiss the dialog. I rebooted and logged on as other users, no solution. It kept trying to sleep, captured keyboard and mouse focus and would not cancel.
At 1:30 the problem disappeared, the Cancel worked.

Similar Messages

  • E71 Mail for Exchange Israel daylight savings bug

    I'm encountering the problem on 2 different phones that work against 2 different Exchange servers.
    If I schedule a meeting through outlook or outlook web access I get the meeting on the phone with the correct time.
    If I schedule a meeting on the phone I get the meeting on outlook and outlook web access with a time shift of one hour.
    I'm using MFE 2.7, Exchange 2003 SP2.
    Thanks in advance for your answers

    This can be solved by changing the time-zone by choosing a location to the east -
    for Israel (GMT+2:00) you can use Qatar (GMT+3:00).
    On the E71:
    1) Menu > Tools > Settings > General > Date and time > Network operator time: set to "off"
    2) Menu > Tools > Settings > General > Date and time > Time zone: set to "Qatar"
    Enjoy

  • AIX 6/7 U.S. Daylight Savings Time bug

    I saw announcements this past Friday and yesterday about daylight savings time bug on IBM AIX and thought this news might be important to pass around, as the time changes in the U.S.  this coming weekend, and the fix requires a system reboot.
    Possible Action Required: System time may not change properly at DST start/end dates on AIX 7.1 and AIX 6.1
    [http://www-01.ibm.com/support/docview.wss?uid=isg3T1013017&myns=pwraix61&myne=E|http://www-01.ibm.com/support/docview.wss?uid=isg3T1013017&myns=pwraix61&myne=E]

    > Apparently, this is far more complicated than either of us might think. I've heard that from several people.
    I don't want to simply sound argumentative (I'm NOT attacking you in any way here), but without some sort of specific evidence of why this would be a complicated issue to fix, I have difficulty believing this. It's easy to say "it's more complicated than you would think," but where is the evidence of this? Where is the statement from Adobe saying that they know about this issue? Where are the examples from the people you refer to that explain why Lr can't do with dozens of other apps -- many of them FREE -- can do without this problem? Are we really supposed to believe that displaying the date/time correctly is so complicated that it's going to take Adobe over a YEAR to fix it?
    We're talking about displaying some text from a standard tag. When it comes to this sort of application, it doesn't get much simpler than this. Lr doesn't have to "calculate" anything -- it just has to display the data in this field. How is this any different than displaying the data from any other field. Why is Lr applying an "adjustment" to a field that doesn't need it? Exactly what is the theory behind this being difficult?
    Thanks for your feedback,
    Larry

  • Weather bug clock did not update to daylight savings

    The weather bug clock did not go to daylight savings time. My Samsung fascinate is new and I checked for updates and there are none.

    My clock was an hour ahead for my home city. I opened Weather bug. Then went to Menu and selected "My city list". I deleted my home city and any other cities. Your homepage will show no city. Then I selected "Select city" on the menu, typed in an found my city again and selected it.Now the time is correct. Finally.

  • Daylight savings all-day events issues in updated iCal for iPad

    After purchasing new MBP, Genius Bar told me to update to new iCal. I have noticed that any all-day events taking place on the date that daylight savings begins (3/13/11 i.e.) lasts on iPad's iCal for two days. When I attempt to edit, event still displays for two days. Guessing it is because that day technically lasts for only 23 hours. Genius Bar consultant had no suggestions for a remedy. This error appears for 2011, 2012, 2013, 2014 daylight savings beginning dates. The error doesn't seem to be a problem for the MBP or my iPhone.

    I've experienced the same problem.  I set up a recurring one day event on the first of each month - come April 1 in 2012 the event is spread over 2 days (the end of daylight savings time in Australia) from April onwards.  I can muck around with the event and have it set at one day from April1 onwards in 2012 but there's a recurring event bug related to daylight savings.  I wonder if any alarms people have set for that day will again experience the problems from the past?

  • 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...

  • 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

  • Site synchronization and daylight savings/standard time

    The familiar problem of Dreamweaver not accounting for the
    change from Daylight Savings to Standard time persists with CS3.
    This only shows up on Windows machines. Windows (tested with both
    XP and Vista) maintains all file times in UTC, and changes the
    locally displayed time based on the time zone. The remote servers
    are all Linux boxes running Apache. DW connection is through SFTP.
    Dreamweaver appears unable to figure out the local time stamp
    offset imposed by Windows. After changing from Daylight Savings to
    Standard time, Check In operations produce a message that all
    remote files are dated an hour later than the local files. This is
    the opposite behavior one sees in the Spring, when the change from
    Standard to DST has Dreamweaver believing all remote files are an
    hour out of date.
    In the past I have manually changed the file modification
    times on all files for every site. Given that this comes to several
    hundred thousand individual files, it is a pain. Searching yet
    again for a method to convince Dreamweaver to correctly interpret
    the file timestamps produced little more than Google's listing
    thousands of search hits for other folks mentioning the same
    problem.
    It made no difference which timezone the server was in (or
    set to) relative to the PC running Dreamweaver. The timezones could
    be identical or different -- DW always complained the remote files
    were an hour later than the local ones. I changed timezones on both
    the server and the local machine. No help. Neither was rebuilding
    the site cache nor manually deleting the WinFileCache*.dat file. I
    also tried manually editing a dwsync.xml file in a _notes folder to
    see if I could alter DW's view of the world. Again, no such luck.
    Making matters far worse, however, Dreamweaver complains
    about file time differences in newly modified files as well. A
    standard Synchronize command produces "Resolve" errors for every
    newly modified file that is not first checked out from the remote
    site using DW, saying both local and remote versions have changed
    since the last sync. Running "Check In" on a newly modified file
    that was not explicitly checked out (e.g. an image or other binary
    file) does nothing, as DW sees a timestamp discrepancy. These files
    must first be Put to the site, with the corresponding DW error
    dialog, and then be checked in.
    I am suspecting the problem stems from Dreamweaver's lack of
    support for the
    MDTM
    command. Many other products, ranging from commercial packages
    such as WS_FTP and Microsoft's Expression Web, to $30 shareware
    programs such as Beyond Compare, to freeware programs including
    WinSCP all correctly interpret Windows timestamps as well as
    preserving the correct time upon file uploads. Is there any
    solution other than changing the timestamps by an hour on every
    file or getting every file from all sites to satisfy Dreamweaver's
    belief that the files are all an hour newer than they actually are?
    The former is a non-trivial task given the sheer number of files to
    change; the latter is a bandwidth PITA for ~90GB of data.
    Message to Adobe: Please fix this problem. It hits users
    connecting Windows local machines to Linux servers twice a year.
    Your competitors as well as shareware authors have sorted this
    matter out.

    Ethan H wrote:
    > The familiar problem of Dreamweaver not accounting for
    the change from Daylight
    > Savings to Standard time persists with CS3.
    Yes, it's a bug, and it's a PITA.
    > Message to Adobe: Please fix this problem.
    Message to Ethan H: This is a user-to-user forum. To get the
    message to
    the right people in Adobe, submit a bug report:
    http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform
    Yes, I'm sure that Adobe knows about the problem without you
    going to
    the effort to submit a report, but the bug report/feature
    request form
    is how the development team assesses its priorities.
    David Powers, Adobe Community Expert
    Author, "The Essential Guide to Dreamweaver CS3" (friends of
    ED)
    Author, "PHP Solutions" (friends of ED)
    http://foundationphp.com/

  • Energy Act of 2005 and Daylight Savings Time

    We currently use Sun Studio compilers. We use the embedded tools.h RogueWave libraries. The Energy Act of 2005 changes the dates for Daylight Savings Time starting in 2007. Will there be any patches from Sun to handle this? We currently use RWZoneSimple which is extensible, but we were hoping for an update from Sun.
    Thanks in advance. Sorry if this has been covered, I just couldn't find anything.
    Further Reading:
    http://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005

    The RW Tools.h++ library that comes with Sun Studio has been updated with the new DST rules. I don't think the patches have been released yet.
    If you have a service contract with Sun, you can get a pre-release version of the patch via your support channel.
    Otherwise, check the Sun Studio patch page from time to time
    http://developers.sun.com/sunstudio/downloads/patches/index.jsp
    Look for a C++ compiler patch that includes a fix for bug 6456479.
    RW Tools.h++ does its own DST calculations. Other libraries rely on the Solaris functions in libc. Patches for Solaris are available now as follows:
    S10 - 118833-24(sparc), 118855-19(x86)
    (The fix is included in S10u2.)
    S 9 - 112874-34(sparc), 114432-24(x86)
    S 8 - 108993-62(sparc), 108994-62(x86)

  • Daylight Savings Time in Calendar Bar

    I am in Australia and we have  also adjusted the clocks to Daylight Savings Time -
    I am using an Iphone  5 with IOS 7.0.2 and all settings are set to time zone Sydney, in both  Date and Time and Calendar.
    The  calendar shows the correct time at the top of the screen but the red  bar that identifies the current time is showing pre DST - quite bizzare?
    My Ipad is showing the same as is my wifes Iphone 5 (also updated with IO7)
    I suggest this is an IO7 glitch/bug - anyone with a solution?  

    It's not just an hour late issue. My 3GS alarm went off an hour early this past Saturday. I tried to reset the alarm for the desired time and it didn't go off. Then my girlfriend's alarm on her 3GS did go off an hour late this morning.

  • Australia Daylight Savings shifted my Calendar by 1 hour

    I'm in Australia on the Optus network. This weekend we went on daylight savings time. The phone picked up the time ok, but now everything in my calendar is off by one hour.
    I have the iPhone synced with my Outlook calendar via Exchange. I've tried everything I can think of on both the phone and in Outlook and nothing works (manually syncing calendar, manually setting time, etc). The times in Outlook are correct though.
    Any ideas?

    Try it again. There's a setting there for time zone which I just discovered. I had the same problem as you yesterday morning (my alarm woke me at 4.00 am instead of 5.00) and I couldn't work out a fix for the problem since I only looked in the time settings under General.
    When I looked at the time zone support settings, I noticed that they were set to the Sydney time zone. I changed that to Brisbane and then changed the time settings in General back to automatic and the time stayed correct.
    I had thought it was a bug in the iPhone's software but now I believe it was simply that I had the time zone set to Brisbane in the General date/time settings and to Sydney in the time zone support settings. It's certainly working fine with both set to Brisbane.
    Why aren't these settings in the one place? That's what I think should be the case.

  • HOw do I fix the fact that ical jumped (almost) all my events post daylight savings time change an hour ahead?

    A few weeks ago I noticed that everything past 3/8 was an hour ahead, and I assumed once daylight savings time changed it would all jump back. It hasn't, and I don't know how to continue scheduling events or if I should change them all.  I read that (a few years ago) the suggestion was give it 24 hours to adjust??

    I think this problem is more complex. Background - UK clocks went back at the end of October; the USA went back one week later. I am in the UK and my Outlook calendar contains appointments created in the USA.
    Someone in the USA created a recurring appointment before any clocks went back. In Outlook everything is correct. The meeting times are the same each week except for the one week between the two clock changes when, quite correctly, the meeting shows up one hour earlier. When I sync with my iPhone, the meeting shows at the same time every week regardless - this is incorrect.
    Someone in the USA created a recurring appointment in the week after the UK clocks went back but before the USA clocks did. Outlook correctly shows the first occurrence as one hour earlier than all the following occurrences. Unfortunately - and this is the really nasty bit - the iPhone shows ALL the appointments one hour earlier than they should be. The only one that is correct is the first one.
    This is a nasty bug and something that Apple needs to fix.

  • EST - Support Daylight Savings Time or not?

    We have found an issue with Daylight Savings Time, the "EST" timezone and Solaris. In Java, the "EST" timezone is flagged as supporting Daylight Savings Time. In Solaris, "EST" does NOT support Daylight Savings Time. The Solaris setting is based on the zoneinfo files that come from ftp://elsie.nci.nih.gov/pub/ (presumably an "official" US Government source). In the "northamerica" file, "EST" is equated to "America/Indianapolis" which is the part of Indiana that does NOT support Daylight Savings Time.
    So, it would appear that Java supporting DST for "EST" would be a bug but I haven't been able to find any other references to this issue. Anyone have any insight on this?
    Mark

    I believe the following example will be of some help.
    java.util.TimeZone zone;
    java.util.Calendar gcal;
    java.text.SimpleDateFormat form = new java.text.SimpleDateFormat("yyyy-MM-dd HH:mm z");
    gcal=new java.util.GregorianCalendar(2004,(4-1),4,14,30);// with default timezone
    long t0=gcal.getTimeInMillis();
    zone = TimeZone.getTimeZone("America/New_York");// New_York
    System.out.println(zone.getID());
    form.setTimeZone(zone);
    gcal.setTimeInMillis(t0);
    System.out.println(form.format(gcal.getTime()));
    zone = TimeZone.getTimeZone("America/Indianapolis");// Indianapolis
    System.out.println(zone.getID());
    form.setTimeZone(zone);
    gcal.setTimeInMillis(t0);
    System.out.println(form.format(gcal.getTime()));

  • Daylight Savings Time...Again

    It's the semi-annual file synchronization crisis, brought to you by Adobe and Daylight Savings Time, now in its nth year!
    My entire 4000+ page site has gone out of synch with my local files due to daylight savings time. Apart from spending hours uploading the entire site, what can I do to maintain proper synchronization? I'd love to see an official tech note addressing this issue. BTW, I do not have any authority over the server to which I post files, so I can't make changes to how the server's timestamps are administered.
    Any solutions/suggestions would be appreciated!

    I've no solution, but just wanted to post to share your frustration. This has been a problem with Dreamweaver for years, and is frankly a major PITA. You'd think such an expensive product worked on by so many coders would have squashed this bug ages ago, but no, plainly the coders can't write simple code which would detect when Daylight Saving kicks in and offer you the option to 'fix' the synch such that files whose timestamps are exactly an hour behind/ahead would be marked as synched. It's not as if it's a tough algorithm, after all. Sadly, DW has become baroque bloatware since being taken over by the Adobe corporate behemoth, which seems intent on building in pointless features so as to generate sales from those eager to keep up with the latest version. I use it because my employer's bought it, but there's no way on this green earth I'd shell out for such a poor product if I had to pay out of my own pocket.
    Just my 2 cent's worth...
    Fred
    PS: Oh, and here's an 'issue' for the board admins. Hitting reply in Firefox 4 doesn't generate this HTML editor, but instead everything just hangs. I've had to go into Safari to reply. No big, it just adds a few mm to the blood pressure and makes the poster even more cross.

  • JRE Update regarding Daylight Savings Time changes

    Hi,
    Is there a JRE Update to be released anytime soon dealing with the US Daylight Savings Time changes?
    A similar update was released for the DST changes in Australia (JRE 1.5.0 Update 6). The link to information page is:
    http://java.sun.com/developer/technicalArticles/Intl/AusTimeZone/
    If there is an update coming for US, when would it be?
    Thanks,
    Vinay.

    If you had read through the bugs related to the one
    whose link was in the post just before yours, you
    would have seen this one:
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=639
    1777
    which appears to answer your question.If I read the bug report right, a fix was made to JDK 1.3.1 to handle the Australia situation. Are you pointing me to the workaround or a potential fix for the US timezone issue?
    The bug report says: "This fix is based on tzdata2006a." Does this tzdata file include an entry for the March 2007 onwards change in the US?
    -Raj

Maybe you are looking for