Daylight Savings Snafu?

This morning, I undocked my iPod and when I docked again, I noticed that some of the podcasts played had the wrong time. The clock was correct this week but I'm wondering if the switch to Daylight Savings time might have caused a problem. I had to reset the time on my iPod as it was on GMT (5 hours ahead). My time zone is Eastern. Anyone else having this issue?
Message was edited by: PatrickJenkins

I'm having the same problem but I'm using a windows machine. If you look at the "Connecting iPod nano (3rd generation) to Windows" catagory, there are a couple of people experencing the same problem. What version of iTunes and iPod are you using? I'm using iTunes 8.0.2.20 (not sure if Mac & Windows are at the same version) and iPod 1.1.3

Similar Messages

IdM Scheduler and Time Change to Daylight Savings Time GMT to BST

This isn't really a 'question' , but just a topic for discussion.
We're not live yet, but will be by the time the clocks go back. So I'm just interest to hear everyone's experiences and any issues with regards to the switching to / from DST
I did some "interesting" (or not) tests last night to see what happens with Pending Values which are due to take effect at the time change threshold of 01:00 GMT when switching to Daylight Savings Time (BST) GMT +0100.
It seems as if the IdM scheduler keeps going according to UTC or GMT. However any values provisioned to target systems or to local tables using the ddm.datetime8601 system variable are in local time according to the runtime server or SQL server's locale settings.
I set up a task to output from a javascript the current system date
using the following in the functions.
currentTime = new Date();
return currentTime.toString(); // returns Locale Time String
currentTime = new Date();
return currentTime.toUTCString(); // returns UTC Time String
in the same pass I also output the ddm.datetime8601 system parameter and the ddm.time24 system parameter.
This task was to update a comment on an entry and Scheduled to run at 00:00:00 and was executed at 00:00:06 GMT all times were still in GMT as expected.
Local Time: Sun Mar 27 00:00:06 GMT-0000 (GMT) 2011, UTC Time: Sun, 27 Mar 2011 00:00:06 GMT, ddm.datetime8601: 2011-03-27T00:00:06, ddm.time24: 00:00:06
This task was scheduled at 01:00:00 in IdM and was exectued at 01:00:08 GMT by the runtime, and you can see the local time is being correctly reported as 02:00:08 BST. Note also the ddmdatetime8061 is also 02:00:08 i.e. BST.
Local Time: Sun Mar 27 02:00:08 GMT+0100 (BST) 2011, UTC Time: Sun, 27 Mar 2011 01:00:08 GMT, ddm.datetime8601: 2011-03-27T02:00:08, ddm.time24: 02:00:08
In the database the entry values MXI_VALUES ModifyTime field has the GMT / UTC timestamp.
I also set up some pending value objects to be applied at 00:59:59 and 01:30:00 to see if the 01:30:00 would be 'skipped' as the locl clock change would've gone from 00:59:59 to 02:00:00. Well the pending values were correctly applied and expired and no 'lost' transactions happened as a result of the change.
So essentially it seems to me that the IdM runtime and scheduler times are all based on UTC / GMT.
I guess it's only an issue twice a year if you're expecting something to happen at a specific local time 01:00:00 or if you've got a global user base and their account expiry should be in each user's own country's local time. In these cases, it would seem that you'd need to convert the schedule times and pending value times to UTC first before setting them in the database.
Has anyone else had any issues, thoughts, questions or suggestioins on scheduling tasks which span the DST time change when switching to and from Daylight Savings Time.
Edited by: Paul Abrahamson on Mar 27, 2011 10:51 AM

Read here:
http://www.appleinsider.com/articles/10/10/11/applesays_ios_software_update_to_fix_pesky_alarm_clockbug.html

Multiple instances spawned after daylight savings time change

This is a known issue and there is an SAP Knowledge Base Article created on this issue:
1448881 - Multiple instances spawned after daylight savings time change
Below is the information from the SAP Knowledge Base Article:
Symptom
Scheduled reports that are supposed to run once a day, run multiple times.
Duplicate instances are being created.
Environment
BusinessObjects Enterprise XIR2 SP5
BusinessObjects Enterprise XIR2 SP5 + FP5.x
Reproducing the Issue
A report is scheduled to be run on a daily basis - this is a Recurring schedule.
Normally the report runs once a day, at a particular time.
After Daylight Savings Time change, the report runs at the specified time, but immediately after the successful instance, another instance is spawned.
Many more instances spawn after each instance completes.
Cause
This is a known issue: ADAPT01318487. This issue is because of DST and how our code handles this change.
Resolution
There is currently no known fix for this issue. There is however a script that can quickly resolve the problem.
The issue it seems is related to Daily recurring schedules.
What this script will do:
it will run a query to display all your DAILY Recurring jobs
you will have the option to choose your jobs and reschedule them by 1 hour
you will then highlight the same job and change them back by 1 hour
by modifying the schedule times, you are modifying the schedule itself and this will keep the issue of duplicate instances from occurring.
Exact Steps to Complete:
Stop the Job Servers.
Double click on the .hta file.
Change the System Name to that of your CMS name.
Add the Administrator's password.
Click Logon.
Click List All Recurring Instances.
Select All.
Make note of what it says in: Schedule Selected Recurring Instances: Should be 1 hr earlier.
Click Reschedule Selected Recurring Instances.
Choose All instances again and change Schedule Selected Recurring Instances to 1 hour Later.
Click Reschedule Selected Recurring Instances.
Now start your Job Servers.
The issue should not occur again.
The Script is attached here, but please review the SAP Knowledge Base article 1448881 as well

Hi Nicola,
- The multiple spawned instances issue ONLY affects XI3 SP3+ only. For XI3 SP1 and SP2 all Fix Pack levels this is not an issue as it was introduced as a problem in SP3.
- 1568239 notes the Java version and can apply to all O/S environments and is updated to reflect that.
If you are located in Europe you can also apply the patches in advance of the DST change to avoid the problem. If you are in Americas at this point utilizing the clean up scripts for this year is the approach needed to clean up the spawned instances and reschedule the existing schedules.
Thanks,
Chris

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?

Iphone calendar off by 1 hour after daylight savings

i have my iphone synced to my outook 2007 through an exchange server. after daylight savings this weekend, all of my appointments are now off by 1 hour. they are all correct in my outlook and on the exchange server (verified by web browser). i've tried deleting the exchange account from the phone and reinstalling, but that doesn't work. also, when i try adding a new appointment on my iphone, it shows up off by one hour in the exchange calendar. my iphone is currently showing the correct time.
anyone know what the heck is going on?

I also had success using this method, from above:
On iPhone, go to Settings>Mail, Contacts, Calendars.
Scroll way down to Time Zone Support. Note that it's listed as GMT-4. Turn slide button to OFF, then back to ON. Note that it automatically goes to Washington, DC (GMT-5).
Calendar appointment times now correct.
Time on the iPhone updated automatically for daylight savings, but the Time Zone Support function didn't make the one-hour shift; they ended up out by an hour from one another. Forcing Time Zone Support to refresh its settings was all that was needed.

Outlook 2011 for mac daylight savings time issue

Hello,
I have a problem in my company where after daylight savings time meetings are shown an hour off in the calendar, but in the body of the meeting the time seems fine. The real problem is when after updating the meeting from it's body (just pressing save and
close) the meeting is bloated by an hour.
E.g. if a meeting after daylight savings time is from 11:00 to 12:00, it's shown on the calendar from 12:00 to 13:00, but after updating the meeting it's shown from 11:00-13:00.
This happens only on the macs in the company.
Thank you.

Hi Harel,
This is the forum to discuss questions and feedback for Windows-based Microsoft Office client. Since your query is directly related to Office for mac, I would suggest you to post in the forum of Office for Mac, where you can get more experienced responses:
http://answers.microsoft.com/en-us/mac/forum/macoffice2011?tab=Threads
The reason why we recommend posting appropriately is you will get the most qualified pool of respondents, and other partners who read the forums regularly can either share their knowledge or learn from your interaction with us. Thank you for your understanding.
Regards,
Ethan Hua
TechNet Community Support
It's recommended to download and install
Configuration Analyzer Tool (OffCAT), which is developed by Microsoft Support teams. Once the tool is installed, you can run it at any time to scan for hundreds of known issues in Office
programs.
Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact
[email protected]

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

Problem with time settings after daylight savings

Ever since the time was returned to normal from daylight savings time, the time on my Blackberry Pearl 8100 is out by one hour (1 hour slow). I set the correct timezone under Date/Time Options and set the Date/Time Source to 'off'. Also, the network time is 7 hours slow since I returned from an overseas trip recently. Can anyone please help?

Sounds like you may need the DST Patch installed on your phone. Go to www.blackberry.com/dst2007 on your device and follow the steps. It is very easy to do

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

No sleep after installing recent java, daylight savings & security updates

After installing the recent java, daylight savings, and the security update, my computer would crash and upon startup would act funny showing a b&W screen with typewriter type asking me to keyboard in directions ie. "shut-down".
I was able to reset the PMU and now it will not sleep on it's own, and when I send it to sleep, it wakes up after a few minutes.

This is for a Mac that won't sleep.
First, read things in Apple doc.#25801 on sleep settings.
Here is Apple doc.#303698 with their tips.
Mine follow;
USB devices and hubs often cause Macs to not sleep or wake quickly from sleep (notably HP printers and scanners, HP all in ones, and Cannon scanners). Disconnect all USB except for keyboard and mouse and try. If it sleeps, add one back at a time testing after each one to find the culprit.
If you've set your Mac to recieve faxes, it may not be able to sleep. It might also have a damaged preferences file.
If you use your Mac for faxing, open System Preferences. click Print & Fax, click the Faxing tab, and uncheck the Recieve Faxes On This Computer box.
If that does'nt work or you've never faxed on your Mac, go to Finder/Hard Drive /Library/Preferences/SystemConfiguration and delete the com.apple.PowerManagement.plist and com..apple.AutoWake.plist files (if your Mac asks, type your admin. password).
If the latter file isn't present in the folder, go to user name(probably your name)/Library/Preferences, delete the com.apple.systemuiserver.plist file, and reboot your Mac.
Hope this helps!
P.S. One member here reported this (Michael Gleason);
"I have had this problem with my IMac G5. It is surprisingly irritating. LaCie's Silverkeeper backup software was the cause. By default it gave itself permission to wake up the computer to check if a backup was needed. Do you have this or a similar program installed which has scheduled activities including wake-up permissions as an option?"
Dave Hamilton provided this link, xlr8yourmac.com, to a member, which addresses failure of deep sleep with some users that updated and added new FireWire and USB cards.
tomhorvat adds this; After few days of messing around I found out that I had desktop background (wallpaper) set to change every 1 minute.
After unchecking "Change picture..." in system preferences (under Desktop/Screen saver), my powerbook went to sleep all by itself.
Cheers!
DALE

Solaris 10 u8 system did not update daylight savings time

I am running Solaris 10 u8 x86, and my system did not update for the daylight savings time change on Nov. 1, 2009. I am in the US/Mountain time zone. What should I do?
Patch 141517-04 is installed, I assume it came with u8.
Does this have something to with JAVA Time Zone updater? I saw this:
http://java.sun.com/javase/timezones/tzdata_versions.html
Shouldn't u8 take care of all this automatically? Do I have to somehow get TZUT 1.3.20? By contacting support? What?
Any suggestions would be greatly appreciated.

BTW, I'm running 64-bit Solaris as a VirtualBox (3.0.10) guest VM on a 32-bit WinXP host.

Entourage Calendar Updated for Daylight Savings

I have used the software update for the adjustment to daylight savings. When I look at my calendar in Entourage, it is showing appointments scheduled after March 11th an hour later than they should be. Will this auto correct when the time changes? What about appointments scheduled now, should I be taking the time change into account?
Thanks,
Sarah
G5 Mac OS X (10.4.8)

Hi Sarah,
I had the same problem. If you click on the Help menu in Entourage, and select "Check for Updates", there are likely two updates you will need. My issue resolved after the first one.
I recommend you use Disk Utitlity to repair your disk permissions before and after you update any software.
Hope this is your solution!
MacBook Mac OS X (10.4.8)

Daylight savings patch - Treo 750 Windows Mobile

Sorry because I see so many items when I search and I just can't find what I need (i just spent an hour on the MS site as well and it kept giving me articles and not downloads.)
Can someone pls provide me the palm update link? I already did the Outlook update last year and thought that was it but I just noticed that my device is now an hour off between the 19th and maybe 26th. I also had to reset the clock on my handheld the day after because it did not change (my computer did, though so I think it is just the device that is 'off.')
thx in advance
Post relates to: Treo 750 (Cingular)

Click here for the Microsoft daylight savings time update page for your Treo.
http://www.microsoft.com/windowsmobile/en-us/downloads/microsoft/daylight-savings-update.mspx
The links to the downloads from this page are in Blue and if you hover the mouse pointer over the Blue text, you will then be able to click and go to the download.
You will need to read through the article and follow the instructions for updating your Treo.
Click on the following link to the kb.palm.com webpage for the article regarding Daylight Saving Time Update for Windows Mobile.
http://www.palm.com/cgi-bin/cso_kbURL.cgi?ID=9314
For reference purposes, click on the following link for the support page for your device on the kb.palm.com webpage.
http://kb.palm.com/SRVS/NUA/launchTab.asp?t=home&fn=treo&mn=750&cn=att
There are links on the page to the user guide, troubleshooting, how to's, downloads, etc.

Wrong timeshift of +1:00h after daylight savings activation

Since the change to daylight savings last Sunday, March 26th, the dates of files displayed in my Finder window are +1:00h newer than the corresponding reference files on my Linux-server. This holds only for files that were actually last modified between October 23rd and March 26th. Unfortunatley, this causes problems in the synchronization between the Linux-File-Server and my PowerBook (I am using ChronoSync). I think that my local Samba-client/Finder on my PowerBook has some intelligent that I would like to switch off. I would appreciate any help in this matter.
Thanks in advance and kind regards,
Joachim

jacky3brown, Welcome to the discussion area!
It sounds like the clock on the "Linux-server" did not make the daylight savings change.

Best Practices for Daylight Savings

Are there any Best Practices to adhere to concerning Daylight Savings around jobs?
Are there White Papers that discuss this issue?
Thanks in advance.

I think each case might be different and you'd have to test for your situation so I don't think you'll find a policy.
We used to set system queue to zero during the time switch...
Not on Tidal 6, we currently let it roll as we didn't see any negative impacts during overnight processing. All our windows servers are 2012 R2. We also don't have jobs that absolutely locked in at a certain time that coincides with Daylight savings. Agents will work on jobs if they were told do by the Master, stay active and report back when they are done regardless of time springing ahead or falling back.

Daylight Savings Snafu?

Similar Messages

Maybe you are looking for