Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > NZ Computing > Apple’s iThings Fail Daylight Saving

Reply
Thread Tools

Apple’s iThings Fail Daylight Saving

 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      10-06-2010
<http://www.theregister.co.uk/2010/10/05/iphone_daylight_saving/>

I thought their OS was supposed to be some kind of BSD-derivative. Which
means, like all POSIXish systems, the system time is in UTC. Which means
that adjusting the clock an hour forward or back for daylight saving is the
wrong thing to do: you need to fix your timezone offset.

So how do they maintain their timezone offset? The usual way of doing this
on Unix/Linux systems is the Olson database (/usr/share/zoneinfo). Did Apple
not do this? Did they do what so many other proprietary vendors have done,
and invent Yet Another Proprietary Timzone Database, which means you need a
vendor-specific system patch to fix bugs or update the database? So if the
vendor is tardy with such a patch, or has decided your OS version is too old
to support, you’re screwed?
 
Reply With Quote
 
 
 
 
victor
Guest
Posts: n/a
 
      10-06-2010
On 7/10/2010 12:08 a.m., Lawrence D'Oliveiro wrote:
> <http://www.theregister.co.uk/2010/10/05/iphone_daylight_saving/>
>
> I thought their OS was supposed to be some kind of BSD-derivative. Which
> means, like all POSIXish systems, the system time is in UTC. Which means
> that adjusting the clock an hour forward or back for daylight saving is the
> wrong thing to do: you need to fix your timezone offset.
>
> So how do they maintain their timezone offset? The usual way of doing this
> on Unix/Linux systems is the Olson database (/usr/share/zoneinfo). Did Apple
> not do this? Did they do what so many other proprietary vendors have done,
> and invent Yet Another Proprietary Timzone Database, which means you need a
> vendor-specific system patch to fix bugs or update the database? So if the
> vendor is tardy with such a patch, or has decided your OS version is too old
> to support, you’re screwed?


Read the article again maybe.
The time updated OK, the bug was just in the repeat alarm settings.
 
Reply With Quote
 
 
 
 
David Empson
Guest
Posts: n/a
 
      10-06-2010
Lawrence D'Oliveiro <(E-Mail Removed)_zealand> wrote:

> <http://www.theregister.co.uk/2010/10/05/iphone_daylight_saving/>
>
> I thought their OS was supposed to be some kind of BSD-derivative. Which
> means, like all POSIXish systems, the system time is in UTC. Which means
> that adjusting the clock an hour forward or back for daylight saving is the
> wrong thing to do: you need to fix your timezone offset.
>
> So how do they maintain their timezone offset? The usual way of doing this
> on Unix/Linux systems is the Olson database (/usr/share/zoneinfo). Did Apple
> not do this? Did they do what so many other proprietary vendors have done,
> and invent Yet Another Proprietary Timzone Database, which means you need a
> vendor-specific system patch to fix bugs or update the database? So if the
> vendor is tardy with such a patch, or has decided your OS version is too old
> to support, you're screwed?


What Victor said. The time/date is fine. There is just a weird bug in
the alarm clock app in iOS 4.0 through 4.1 (apparently fixed in iOS 4.2
beta) which causes repeating alarms to go off an hour early in some time
zones (including NZDT and Australia daylight time). I filed a bug report
with Apple but someone just beat me to it, and mine got closed as a
duplicate.

It doesn't affect one-off alarms, didn't affect iOS 3.1.3 or earlier,
and I haven't noticed anything else getting the time wrong.

And to answer your question, iOS is almost certainly using the same time
architecture as Mac OS X and typical BSD Unix systems, where the system
operates on UTC internally and converts to local time based on
/usr/share/zoneinfo. The question could be answered conclusively by
someone with a jailbroken iOS device.

--
David Empson
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Enkidu
Guest
Posts: n/a
 
      10-06-2010
On 07/10/10 06:33, whoisthis wrote:
> In article<i8hlm6$fs7$(E-Mail Removed)-september.org>,
> victor<(E-Mail Removed)> wrote:
>
>> On 7/10/2010 12:08 a.m., Lawrence D'Oliveiro wrote:
>>> <http://www.theregister.co.uk/2010/10/05/iphone_daylight_saving/>
>>>
>>> I thought their OS was supposed to be some kind of BSD-derivative. Which
>>> means, like all POSIXish systems, the system time is in UTC. Which means
>>> that adjusting the clock an hour forward or back for daylight saving is the
>>> wrong thing to do: you need to fix your timezone offset.
>>>
>>> So how do they maintain their timezone offset? The usual way of doing this
>>> on Unix/Linux systems is the Olson database (/usr/share/zoneinfo). Did Apple
>>> not do this? Did they do what so many other proprietary vendors have done,
>>> and invent Yet Another Proprietary Timzone Database, which means you need a
>>> vendor-specific system patch to fix bugs or update the database? So if the
>>> vendor is tardy with such a patch, or has decided your OS version is too old
>>> to support, you’re screwed?

>>
>> Read the article again maybe.
>> The time updated OK, the bug was just in the repeat alarm settings.

>
> yep, had to adjust my alarms.
> LDO is best filtered out, he trawls though the net finding article that
> are anti-mac/anti-windows with the mindless and simplistic belief that
> we will all throw our hands in the air and become linux users, and we
> all (except him) know thats not going to happen.
>

We all know that Mac users are liberal pinko communists.

Cheers,

Cliff

--

The ends justifies the means - Niccol di Bernardo dei Machiavelli.

The end excuses any evil - Sophocles
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      10-07-2010
In message <1jpyxp8.1acm3vwngtq0sN%(E-Mail Removed)>, David Empson
wrote:

> And to answer your question, iOS is almost certainly using the same time
> architecture as Mac OS X and typical BSD Unix systems, where the system
> operates on UTC internally and converts to local time based on
> /usr/share/zoneinfo.


But you previously said that Apple was using IBM’s “ICU” mechanism
<http://groups.google.co.nz/group/comp.sys.mac.system/msg/c3613ce794020b6d>:

This means that to update Mac OS X for daylight saving rule changes, it
is necessary to patch both the zoneinfo files and the global ICU data
files. If you patch one and not the other, some applications (including
iCal) get very confused because they are using both the CoreFoundation
calls and the C standard library calls. Observed symptoms include iCal
thinking that October 2007 is also called September.

Could such symptoms also include alarms going off at the wrong time?
 
Reply With Quote
 
victor
Guest
Posts: n/a
 
      10-07-2010
On 7/10/2010 8:48 a.m., Robert Cooze wrote:
> On 07/10/10 06:33, whoisthis wrote:
>> In article<i8hlm6$fs7$(E-Mail Removed)-september.org>,
>> victor<(E-Mail Removed)> wrote:
>>
>>> On 7/10/2010 12:08 a.m., Lawrence D'Oliveiro wrote:
>>>> <http://www.theregister.co.uk/2010/10/05/iphone_daylight_saving/>
>>>>
>>>> I thought their OS was supposed to be some kind of BSD-derivative.
>>>> Which
>>>> means, like all POSIXish systems, the system time is in UTC. Which
>>>> means
>>>> that adjusting the clock an hour forward or back for daylight saving
>>>> is the
>>>> wrong thing to do: you need to fix your timezone offset.
>>>>
>>>> So how do they maintain their timezone offset? The usual way of
>>>> doing this
>>>> on Unix/Linux systems is the Olson database (/usr/share/zoneinfo).
>>>> Did Apple
>>>> not do this? Did they do what so many other proprietary vendors have
>>>> done,
>>>> and invent Yet Another Proprietary Timzone Database, which means you
>>>> need a
>>>> vendor-specific system patch to fix bugs or update the database? So
>>>> if the
>>>> vendor is tardy with such a patch, or has decided your OS version is
>>>> too old
>>>> to support, you’re screwed?
>>>
>>> Read the article again maybe.
>>> The time updated OK, the bug was just in the repeat alarm settings.

>>
>> yep, had to adjust my alarms.
>> LDO is best filtered out, he trawls though the net finding article that
>> are anti-mac/anti-windows with the mindless and simplistic belief that
>> we will all throw our hands in the air and become linux users, and we
>> all (except him) know thats not going to happen.

>
> But in all seriousness, I have had many phones in the past. Those that
> had a repeating alarm never did this trick if the clock was set correct.
> two of those phones used there own OP system. I suppose the sheep in NZ
> should take it back to where they bought it to get it fixed and that
> would be my expectation of it is a consumer device after all.
>
>

It's a bug, they will probably issue an update for that.
Since it happened only to people that had upgraded, they will be
familiar with Apples update methods, but I don't think it would be a
problem if you took it back to the retailer and got them to do the
update either.
I suppose that receiving criticism from nz.comp might make a difference
to Apples response, but it seems unlikely and a tad ritualistic.

--
"I'm completely operational, and all my circuits are functioning perfectly."
 
Reply With Quote
 
David Empson
Guest
Posts: n/a
 
      10-07-2010
Lawrence D'Oliveiro <(E-Mail Removed)_zealand> wrote:

> In message <1jpyxp8.1acm3vwngtq0sN%(E-Mail Removed)>, David Empson
> wrote:
>
> > And to answer your question, iOS is almost certainly using the same time
> > architecture as Mac OS X and typical BSD Unix systems, where the system
> > operates on UTC internally and converts to local time based on
> > /usr/share/zoneinfo.

>
> But you previously said that Apple was using IBM's "ICU" mechanism
> <http://groups.google.co.nz/group/comp.sys.mac.system/msg/c3613ce794020b6d>:
>
> This means that to update Mac OS X for daylight saving rule changes, it
> is necessary to patch both the zoneinfo files and the global ICU data
> files. If you patch one and not the other, some applications (including
> iCal) get very confused because they are using both the CoreFoundation
> calls and the C standard library calls. Observed symptoms include iCal
> thinking that October 2007 is also called September.


True, I'd forgotten that detail. I don't know whether iOS has inherited
that particular dual mode of operation, but it seems likely as
CoreFoundation is/was using ICU on Mac OS X, and CoreFoundation is also
used on iOS. (I'd need a jailbroken iOS device to have a look at the
relevant part of the file system.)

> Could such symptoms also include alarms going off at the wrong time?


Potentially, if Apple had updated one database but not the other one.

That isn't the case here, because if the iPhone had two databases which
had different transitions for NZDT, the old rules would have resulted in
the daylight saving transition happening a week later, and the alarms
would have only been wrong during the week where the rules differed.

We're past that point and recurring alarms are still going off an hour
earlier than the time specified on the alarm, so the bug is somewhere
else.

It is a weird bug. In UTC, the alarms are happening two hours earlier
than they were before the daylight saving transition (should have been
one hour earlier).

- Alarm is set for 8 a.m. (say).
- While in NZST, the alarm fires at 8 a.m. NZST (UTC+12).
- While in NZDT, the alarm fires at 7 a.m. NZDT (UTC+13), which is 6
a.m. NZST.

The behaviour is like the timed alarm mechanism is manually applying a
daylight saving correction on top of the one automatically applied by
the OS, but only for one sort of alarm.

--
David Empson
(E-Mail Removed)
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      10-07-2010
In message <1jq00o2.1o68ca51unrt1kN%(E-Mail Removed)>, David Empson
wrote:

> The behaviour is like the timed alarm mechanism is manually applying a
> daylight saving correction on top of the one automatically applied by
> the OS, but only for one sort of alarm.


Written by people who aren’t used to doing time calculations in UTC, in
other words.
 
Reply With Quote
 
victor
Guest
Posts: n/a
 
      10-07-2010
On 8/10/2010 12:15 p.m., Lawrence D'Oliveiro wrote:
> In message<1jq00o2.1o68ca51unrt1kN%(E-Mail Removed) .nz>, David Empson
> wrote:
>
>> The behaviour is like the timed alarm mechanism is manually applying a
>> daylight saving correction on top of the one automatically applied by
>> the OS, but only for one sort of alarm.

>
> Written by people who aren’t used to doing time calculations in UTC, in
> other words.


It worked in iOS 3 though, so its more likely some time variable that
has been renamed and not picked up by the alarm clock application
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      10-07-2010
In message <i8llo0$8kh$(E-Mail Removed)-september.org>, victor wrote:

> On 8/10/2010 12:15 p.m., Lawrence D'Oliveiro wrote:
>
>> In message<1jq00o2.1o68ca51unrt1kN%(E-Mail Removed) .nz>, David Empson
>> wrote:
>>
>>> The behaviour is like the timed alarm mechanism is manually applying a
>>> daylight saving correction on top of the one automatically applied by
>>> the OS, but only for one sort of alarm.

>>
>> Written by people who aren’t used to doing time calculations in UTC, in
>> other words.

>
> It worked in iOS 3 though, so its more likely some time variable that
> has been renamed and not picked up by the alarm clock application


The question is, why is any app second-guessing the OS over timezone
conversions? On any POSIX system introduced over the last 20 years, if you
want the system time in UTC, you call the time(2) routine. If you want local
time broken down to year, month, day, hours, minutes and seconds, you call
localtime(3). If you want to do adjustments to local time, you can convert
the result back to UTC with mktime(3).

No need for you to do any adjustment, the system manages all those headaches
for you. That way, if there are any changes to the rules, only the system
needs a single update, the apps don’t.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to convert a given local time to UT considering Daylight Saving Times.... Filip Lyncker C++ 3 04-05-2005 02:52 PM
Daylight saving Amitabh Deepak C++ 4 09-17-2004 12:38 PM
Daylight saving 2004-10-31 03:00 EEST/EET? NoName NoName Java 0 04-12-2004 07:21 PM
Daylight Saving time: How to identify if a given time is invalid? Pranav Kantawala Java 5 02-25-2004 06:28 PM
Converting datetimes from/to UTC/GMT including daylight saving Michael Pfeifer C++ 4 12-17-2003 09:18 PM



Advertisments