IPhoto 9.2.1 displaying wrong time on photo after changing back from daylight savings time

Europe went back to standard time (from daylight savings time) on Sunday morning, Oct. 30. In my Nikon D7000 I changed the time accordingly by retaining the time zone (UTC+1) but switching Daylight Savings to OFF. The times on the photos display correctly in the camera and in Finder. They also display correctly in EXIF-O-Matic. In iPhoto 9.2.1, however, they display with one hour added. Has anybody else encountered this problem?
Just tried to reproduce the error but could not. Without changing any of the time zone settings I shot a photo and imported it into iPhoto. The time in iPhoto is now correct. I am absolutely sure that I set Daylight Savings to OFF in the camera before taking any photos on Oct. 30. Perhaps the problem has to do with importing on Oct. 30, the day of the change?
Regards,
Richard

You should not be importing that Library.
Never import one Library to another. Every version and thumbnail is imported like a distinct photo, you lose all your Albums, Keywords etc., the link between Original and Previews is destroyed, the non-destructive editing feature is ruined and so on. In summary: it's mess.
You simply restore the Library from Time Machine and then open it.
Regards
TD

Similar Messages

Appointments one hour ahead of appointments created in iCloud - both before *and* after the shift from daylight savings time

I am in the CET timezone and my Lumia 925 on 8.1 has consistently shown appointments one hour ahead of appointments created in iCloud - both before and after the shift from daylight savings time here.
My disappointment is compounded by the fact that I patiently waited for October, naïvely thinking the clockchange would solve things... doh.
Look forward to your earliest solution.
Jonny.

There is a separate thread on this subject. It's a bug in Windows Phone 8.1. It is fixed in the upcoming Windows 8.1 Update 1 release (due Nov/Dec 2014). Alternatively, you can install the developer preview (go to Store and search for 'preview for developers'.
You have to register as a developer though (easily done through appstudio.windows.com) or you can wait for your phone vendor (Microsoft / Nokia) to release the 'Denim' upgrade.
For now, I don't know a decent workaround.

ICal times changed with change from Daylight savings time

My times on iCal on my G5 are correct. I transferred them to my iPod through iTunes. But when I changed the time from Daylight savings time Sat, my times on my iPod's iCal all moved an hour earlier. However, an event that I added today has the correct time. Besides having my iPod clock set for the wrong time, how do I correct the times in my iCal?

I now have a follow-up problem. Almost everything is right in my iPod calendar as I deleted and then manually added repeated events for Mon, Tue, Thurs, Fri, Sat, and Sun. into my G5 iCal. Mondays, Wednesdays, Thursdays, Fridays, Saturdays, and Sundays are correct in the iPod. However, my Tuesdays show both my Monday AND Tuesday events. Have you run into that problem?

6234 Change to/from daylight saving time or summer...

We have just changed back to winter time, and I am sure that there is a way to make the phone change, without setting the time. I can only find time zones, and have set it to GMT (which is my local zone), but even so, I am sure that there is another menu item somewhere to change to and from summer time. The phone time did not change, so it was already on the right time zone.
I've looked in the user guide, but there is no mention of it.
I can't remember what I did 6 months ago.

hi Peter,
same problem-just gone to winter time (UK)and my 6500s was also set to auto but never changed i evan left it an extra day thinking that i too may have missed a setting or something simelar but had to change it manually today after finally giving up.Thing is this will really bug me til i can solve it.

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

2007 Daylight Savings Time Changes

What, if any, effects will the 2007 changes to US daylight savings time have on the operation of the LabVIEW 7 Express development environment and deployed applications created with it?

I believe the answer depends on the OS the application runs under.
If MS has there act together and the machine in question has recieved updates, there should be no issue.
If you are running Unix (or a variation o such), a patch must be applied (at least that was the story my wife gave for working all night Saturday night).
I can not answer this Q for Mac or LV-RT running under Pharlap.
Ben
Message Edited by Ben on 02-27-2007 10:24 AM
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

E-Load/e-ME and Daylight Savings Time Change

If you are using e-TEST suite versions 8.10 or older, please see the following knowledge base article on updating your JRE for e-Load and e-Manager Enterprise.
http://qazone.empirix.com/entry.jspa?externalID=201&categoryID=15
(you must be logged into QAZone to view this link)
It is recommended that e-Load and e-Manager Enterprise customers update the JRE on their e-Load and e-ME server machines using the SUN JRE patch referenced in the article.
e-TEST suite version 8.20 which is releasing this week does not require any update.
Message was edited by: jfernandes

My problem is that now CFMX 6.1 thinks that it is 8 hours
later in the day
than it really is (it is stuck on GMT now) and I am unable to
get CFMX to
acknowledge the operating systems clock. :-(
"GregK" <[email protected]> wrote in message
news:eord35$5mq$[email protected]..
The technote for this issue:
http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=d2ab4470
has
another
link to a technote which addresses null pointer exceptions
after upgrading
the
JVM on CFMX 6.1 systems:
http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=kb400232
The hotfix
described in that technote gives a fix for CFLDAP and
CFSERVLET tags after
the
new JVM is installed.
The important thing to note is that Adobe feels that
daylight savings time
will indeed present a problem for ColdFusion applications.
Unfortunately,
the
problems are not explained in any detail. I can guess that
functions like
DateDiff( ) may calculate incorrect values when spanning the
changed weeks
of
daylight savings time. As others have suggested; however,
simply retrieving
the system time, i.e. Now( ) function may not be affected as
long as the
operating system clock is set correctly.
Hope that helps.

CF MX and Daylight Savings Time Change

Next year 2007, the Daylight Saving day (chaning the clocks
for spring and fall) will be changing. The Spring date will be a
month earlier and the fall date a month later then it has been for
years.
How will the Cold Fusion Server for MX 7+ handle this? Will
it use the server time or use the internal CF Server clock?
Thanks.

My problem is that now CFMX 6.1 thinks that it is 8 hours
later in the day
than it really is (it is stuck on GMT now) and I am unable to
get CFMX to
acknowledge the operating systems clock. :-(
"GregK" <[email protected]> wrote in message
news:eord35$5mq$[email protected]..
The technote for this issue:
http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=d2ab4470
has
another
link to a technote which addresses null pointer exceptions
after upgrading
the
JVM on CFMX 6.1 systems:
http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=kb400232
The hotfix
described in that technote gives a fix for CFLDAP and
CFSERVLET tags after
the
new JVM is installed.
The important thing to note is that Adobe feels that
daylight savings time
will indeed present a problem for ColdFusion applications.
Unfortunately,
the
problems are not explained in any detail. I can guess that
functions like
DateDiff( ) may calculate incorrect values when spanning the
changed weeks
of
daylight savings time. As others have suggested; however,
simply retrieving
the system time, i.e. Now( ) function may not be affected as
long as the
operating system clock is set correctly.
Hope that helps.

All Event times change with Daylight Savings time

With the time change associated with daylight savings time (March 8 2008) all my event times were changed by one hour. EG: events that were 8:45 am are now 7:45 am. I have tried using Time machine to restore to pre March 8 status,but an adjustment takes place and the events remain 1 hour ahead. I have looked through the discussions pages and don't even see the issue identified. I have looked through the menu and preference items and find nothing to help.
I am surprised not to find this a front page topic today, March 9 2008.
Can anyone offer some help ?
Bill Mullen

Michael,
I never have changed time zones. Are you suggesting I should have time zone support enabled ?
I just tried turning on Time Zone Support, then restoring my calendar using Time machine. No change here.
As I mentioned earlier, this same problem occurred in the fall (although I don't remember which way the event times moved), this time they moved forward. At the Fall change I was using a Mac G4, which I used as a target to build this machine. The only thing I can think of that makes me unique (although I'm not in that small of a group) is that I have altered one of the files in iSync to allow iSync to sync calendar events with iCal. The syncing has always worked OK.
Right now I'm leary of attempting to do anything with iSync. I'm also finding it difficult to believe I'm not one of 10,000 people experiencing the same problem, but I don't see any other posts.
I found a time zone in south america which returns my times to the correct figure, with time zone support enabled, but that looks like a deeper hole to dig out of.
Still stuck,
Bill

Cron job and daylight savings time

What is the behaviour of cron when the time changes from daylight savings time to standard time and vice versa ?

This has been discussed at length in
http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?forumid=1&catid=7&threadid=12 44419&highlight_key=y&keyword1=dst

How to fix daylight savings time switch

Times jumped ahead several weeks ago for daylight savings time, and I dont know whether to change them all manually or not.

thanks for responding ; I just changed all my entries after Sunday manually just now. I'd waited over 36 hours and it hadn't adjusted. Sure hope this doesn't happen everytime there's a time change -- I don;t remember it happening before.

Australian daylight savings time wrong under Mac OS X 10.7

The 'set date and time automatically' option displays the wrong time under Mac OS X 10.7 in Australia. I use Apple Asia (time.asia.apple.com) and I don't think it accounts for daylight savings time. I know I have the option the set the time manually, so it is not a large problem, However I'm just raising the issue. The time currently in Australia is 5:45pm and my computer running Lion displays 4:45pm. My iPhone running iOS 5 has no issues and displays the right time.

markpb91 wrote:
Coffs Harbour, northern NSW along the coast. So I'm on Sydney AES time.
Beautiful part of the world! I have under Date and Time in System Preference marked as such
Date and Time    South Asia (have set automatically unticked)
Then Time Zone set for Australian Eastern Daylight saving time
                                   Melbourne - Australia    (I'm in Ballarat)
                                   With set time automatically up the top unticked
They are the settings I have always used and my computers have always reverted to and from Daylight savings (except of course I'm in Queensland, Then I have to reset my location and remember to set it back.
Other than that if may come down to trashing your pref file for date and time.
Good Luck

Daylight Savings time, and how dates are stored internally and displayed

This is probably a question that appears here annually, but I couldn't really find clear answers, so I'll try asking this in my own words:
I'm in the Eastern timezone, and this Sunday, we'll be turning our clocks back an hour at 2:00 AM. That means that accordign to us humans, the time 1:30 AM will occur twice on Sunday.
I've got an Oracle application that runs every 5 minutes around the clock, and it selects records from a certain table whose updated timestamp (TIMESTAMP(6)) is greater than SYSDATE - 5/1440, meaning any record that was updated in the last 5 minutes. Will we have a problem with some records being processed twice on Sunday morning? I'm theorizing that everything will be OK, that internally, Oracle stores DATE fields using something like an epoch which then gets interpreted when we display them. An epoch value will continue to grow each second no matter what “time” it is according to the U.S. Congress.
A simpler way to look at the question might be as follows:
If you store SYSDATE in a DATE column in row “X” at 1:30 AM before the time change, and you store sysdate in row “Y” exactly one hour later, will Oracle say that X’s timestamp is 60 minutes less than Y’s timestamp? All fields that are related to my particular situation are either DATE or TIMESTAMP(6).
We use 11g.

>
That settles that! Thank you! My theory was wrong! I appreciate the help.
>
You may think it settles that but, sorry to burst your bubble, that doesn't really settle much of anything.
One thing that was settled is the answer to this question
>
But are they talking about what you can EXTRACT and DISPLAY from the field or what is actually STORED internally?
>
which is, as Mark stated, they are talking about what is stored internally.
The other thing that was settled is that you will pull the same, or mostly the same, data twice during that one hour. I say 'mostly the same' because of the major flaw your extraction method has to begin with.
>
If you store SYSDATE in a DATE column in row “X” at 1:30 AM before the time change, and you store sysdate in row “Y” exactly one hour later, will Oracle say that X’s timestamp is 60 minutes less than Y’s timestamp?
>
No - they will have the same time since 'one hour later' would have been 2:30 AM but the clock was turned back an hour so is again 1:30 AM. So the second time your job runs for 5 minutes at 1:30 AM it will pull both the original 1:30 AM data AND the data inserted an hour later.
And Oracle will say that data stored in row "Z" exactly 45 minutes later than "X" at 1:30 AM will have a date of 1:15 AM and will appear to have been stored earlier.
Your method of extracting data is seriously flawed to begin with so the daylight savings time issue is the least of your problems. The reason is related to the answer to this question you asked
>
do people avoid using DATE and TIMESTAMP datatypes because they are too simple?
>
That method isn't reliable - that is why people avoid using a date/timestamp value for pulling data. And the more often you pull data the worse the problems will be.
>
I've got an Oracle application that runs every 5 minutes around the clock, and it selects records from a certain table whose updated timestamp (TIMESTAMP(6)) is greater than SYSDATE - 5/1440, meaning any record that was updated in the last 5 minutes
>
No - it doesn't do that at all, at least not reliably. And THAT is the why your method is seriously flawed.
The reason is that the value that you use for that DATE or TIMESTAMP column (e.g. SYSDATE) is assigned BEFORE the transaction is committed. But your code that extracts the data is only pulling data for values that HAVE BEEN committed.
1. A transaction begins at 11:59 AM and performs an INSERT of one (or any number) of records. The value of SYSDATE used is 11:59 AM.
2. The transaction is COMMITTED at 12:03 AM.
3. Your job, which runs every five minutes pulls data for the period 11:55:00 AM to 11:59:59 AM. This job will NOT see the records inserted in step #1 because they had not been committed when your job query began execution - read consistency
4. Your job next pulls data for the period 12:00:00 AM to 12:04:59 AM. This job will also NOT see the records inserted in step #1 because the SYSDATE value used was 11:59 AM which is BEFORE this jobs time range.
You have one or ANY NUMBER of records that ARE NEVER PULLED!
That is why people don't (or shouldn't) use DATE/TIMESTAMP values for pulling data. If you only pull data once per day (e.g. after midnight to get 'yesterdays' data) then the only data you will miss is for data where the transaction began before midnight but the commit happened after midnight. Some environments have no, or very little, activity at that time of night and so may never have a 'missing data' problem.
Creating your tables with ROW DEPENDENCIES will store an SCN at the row level (at a cost of about 6 bytes per row) and you can use the commit SCN to pull data.
Just another caveat though - either of those approaches will still NEVER detect rows that have been deleted. So if you need those you need yet a different approach such as using a materialized view log that captures ALL changes.

Has anyone had problems in v5.0a of Iplanet calendar installed on a Sun box with creating events and daylight savings time?

Events created around 4/6/2002 at 8pm get created with the wrong time (9pm) and there are several other creation and display problems tied to Daylight Savings in April and October. Version 5.1 of the software seems to fix that but we are looking for a fix until we can upgrade. We have been using Windows systems to access the calendar.
Thanks.

We have not seen exactly this, but many users appointments are lining up in the wrong time slots. Also, when scheduling, the time display is off by an hour. We have found what looks like a temporary fix.
We noticed that the problem only affects users who have the start of the week set to Sunday (when daylight savings time started). Setting the week to start on Monday fixed our display problems (you can do it in the users, options section).
I am placing a support call w/SUN.

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

IPhoto 9.2.1 displaying wrong time on photo after changing back from daylight savings time

Similar Messages

Maybe you are looking for