Daylight savings time and recurring alarms -- FIX IT ALREADY APPLE!

Jeeze Louise! Apple has only known about the iPhone clock being unable to cope with recurrent alarms since LAST September when DST ended in Australia. iOS 4.2 did not fix it by the way. Nice how it wasn't released until -after- the entire Southern Hemisphere had already been late for stuff. Maybe most folks didn't have to work til Monday & caught on that there was a bug, but that's no comfort for we who work on Sundays.
November I was early for work. Today was a different story. What the H-E-- Apple?? It's a CLOCK. None of my previous phones (circa 2006) with recurring alarm features had this problem. Maybe 4.2 "fixed" the fall back issue; guess we'll see this November. But good Lord! Can't they fix it both ways? I shouldn't have to plug in my old geezerly Nokia just to have a reliable alarm twice a year for DST. I'm not really I interested in a "work around" as at the price we pay for iPhones, this ought not be happening!

And I just love how Apple doesn't have any way on their site to actually contact THEM when their customers have a complaint (or even a suggestion) about one of their products. No, we can only call during their office hours, at their convenience, not ours. We are left to ask fellow users for assistance we ought to be getting from the bloody Makers of our items. Who are likely just as ****** off & clueless as we are. Joy.

Similar Messages

Daylight Savings Time and Alarmsk

Since the daylight savings time updated over the weekend the alarms I had programmed on my iPhone will not set properly. The phone displays the correct current time so I know the clock has updated but any alarms I have set for the hour of 2am - 3am don't display the proper time. They keep reverting to 1-2am. I have deleted them and recreated them with the same results, on 2 different iPhones, a 4gig and an 8gig.

I see im not the only one that gets up early. v1.1.3 and updated to 1.1.4 I am unable to set the alarm to any time in 2AM (2:01, 3, 4, 5, etc..) any time set to 2AM shows 1AM in the alarm. 2PM shows fine. Any hour of the day shows fine. The error is setting a time of 2AM as it will not show that time and will revert to 1AM.
I am in a zone that uses DST.
I guess apple doesnt want us to wake up to pay the bills.
I hope someone has a fix for this before I goto bed... busting out the old alarm clock now.

Daylight Savings Time and Calendar?

What will happen to my iPhone calendar events come daylight savings time?

I have had that problem on my mac and iPhone. In my calendar it shows one hour later and even on my alarm clock app it is changing times, just odd random things.
On my iPhone I changed the time setting and it did not help. I am avoiding doing a total wipe and restore or whatever, because I don't want to go through the hassle of re doing everything.
I keep fixing my calendar and it keeps giving me trouble. Let me know if anybody has any ideas.

Daylight Savings Time and Time Zone Issue:

Howdy! Many of us woke up this morning to be dismayed to find that our iPhone was TWO hours behind instead of falling back one for the Daylight Savings Time adjustment, and were late for church. I have an iPhone 4S, with iOS 5...
I was working at that time of morning, and the initial switch went well. However, when I woke up, the clock was yet another hour behind. A little investigation showed that the Time zone had been changed to Denver (It was previously on Chicaco, and I live in Dallas.) I tried to select it to change it, and it wouldn't allow me. If I turned off the Set Automatically feature, then I could change it, but when I turned the Set Automatically feature back on, it would re-set the time zone to Denver.
I found another thread where they discuss this:
https://discussions.apple.com/message/16644669
To fix this, put in airplane mode, then back out again, then re-choose your correct time zone. If this doesn't work, then try turning your phone completely off and then on again. Thanks to 4n6doc for the tip!
The airplane mode trick worked for me: I turned airplane mode on, then off, then went to the Date & Time and set my time zone to Dallas, TX while the Set Automatically was off. When I turned the Set Automatically back on, it changed Dallas to Chicago, which is what every iPhone iOS I've ever had has done.

Hi,
Yes this is a correct way to fix the issue. One thing however, how did you set the timezone? For correct daylight saving handling, you'll have to use the long version, like America/New Yorw, NOT GMT-5 (for example).
regards,
~ Simon

Daylight savings time and solaris 10

Does anyone know if Solaris 10 users have to install a patch for the Daylight Savings Time issue?
Thank you
LM

I have used RealVNC Free program (http://www.realvnc.com)in all my systems with no problem, if interested hereis a quick way to install it.:
File to use: �vnc-4_1_2-sparc_solaris.tar.gz�
#gunzip vnc-4_1_2-sparc_solaris.tar.gz
#tar �xvf vnc-4_1_2-sparc_solaris.tar
#cd vnc-4_1_2-sparc_solaris
b)
Install it by running:
# ./vncinstall /usr/bin /usr/share/man
Note: this will also install man pages into �/usr/share/man/man1�
If you want to use the Java VNC viewer (Open browser and type pc_name:display#):
Copy the files from the java directory to some suitable installation directory
such as /usr/local/vnc/classes (vncserver will read this path!- don�t change it):
# mkdir -p /usr/local/vnc/classes
# cp java/* /usr/local/vnc/classes
c)
Add to the .profile file (under the user):
vncserver -depth 24 -geometry 1024x768
d)
under the user:
Create a /.vnc directory first, we will create the xstartup file inside:
file /.vnc/xstartup:
#!/bin/sh
xsetroot -solid grey
gnome-session <note: if you want to use gnome as the defualt >
#/usr/dt/bin/dtsession <note: if you want to use CDE as the default >
make the 'xstartup' file executable:
# chmod 744 xstartup
*** Sample used for the user: (use the same file for the other users) �it will be created
the first time using it, just change it/add to the following sample:
First time to login will ask to create a password or
Run /export/home/�name�/.vnc/passwd (to add password to login)
If Needed, change ownership on the following 3 if you create them using root user:
/.vnc folder
/.vnc/xstartup
/.vnc/passwd
Message was edited by:
murilloa

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.

Daylight savings time and iPhone 4 alarm bug NOW FIXED???

OK this morning i turned on my alarm and put it 1h ahead (the alarm is on repeat for the rest of the week) so the alarm goes off at the right time cos of the alarm bug.
but this morning my alarm was set at 6:45am and went off at 6:45am rather then 7:45am (if the bug was still present)
i have not changed my alarm and they are all repeat alarms. last week i fixed this problem by making my repeat alarm 1h ahead then normal.
i am now confused if this issue has been fixed.
Has this happened to anyone els?

Thanks wjosten.
I had been keeping an eye on this alarm bug but did not no thing changed on the 7th, guess i did not look hard enough.
would be nice is apple had a mailing list for these kinda things. so they can inform you of an error like this
well i am not in a rush for the 4.2 patch now sis the alarm is now working. they have now got like 5 odd months to fix this.
looks like apple is going on the same way as windows

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.

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.

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.

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.

COREid and Daylight Savings Time for 2007

Do COREid or any of its components require any special fix in order to comply or function properly with the new Daylight Savings Time for 2007?
Background:
In August of 2005 the United States Congress passed the Energy Policy Act,
which changes the dates of both the start and end of daylight saving time
(DST). When this law goes into effect in 2007, DST will start three weeks
earlier (2:00 A.M. on the second Sunday in March) and will end one week later
(2:00 A.M. on the first Sunday in November) than what had traditionally
occurred.
Thanks,
Craig
Message was edited by:
user557097

We have experienced many problems with DST and COREid in the past; most of them resulting in hung Access server and unavailability. I don't know if it's because we have components distributed across multiple time zones or what. Our plan is to have someone available at the time change to cycle the services (and maybe the server as a whole) and do a health check after the fact. I hope this helps.
--Aaron

All-day calendar entries and daylight savings time

Since changing to daylight savings time, whenever I change the date on an all-day calendar entry, my iPad (but not my iPhone) changes the one-day calendar entry to a two-da calendar entry. How do I correct this?

Dates are represented internally with a long that represents the number of milliseconds past some fixed point. Timezones do not affect this.
I'm assuming you're getting your dates as java.sql.Date
You should then build a Calendar (see GregorianCalendar) and call setTimeZone() with your timezone without daylight savings

Having problems setting alarm time since daylight savings time change today

Since the change to Daylight Savings time this morning, I am unable to set my alarm correctly. I set it to 2:40 a.m. but the time on the alarm shows 3:40 a.m. I have all the proper settings correctly done. I have powered down the phone numerous times, and still the same result. Any assistance would be greatly appreciated.

I've cleared the clock cache, powered off the phone and the problem remains the same. I have the Automatic date & time checked, and the same for Automatic time zone (GMT-5:00, Eastern Daylight Time). I have even unchecked both and still get the same result.
What is weird, I can set the alarm for any other time, but unable to set it at 2:40 a.m. When I do this, it sets to 3:40 a.m. Any time that I set from 2:00 a.m. to 2:59 a.m. goes to that time setting in the 3 a.m. time.

Daylight savings time and recurring alarms -- FIX IT ALREADY APPLE!

Similar Messages

Maybe you are looking for