«

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

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.

Lawrence D'Oliveiro <_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

On 07/10/10 06:33, whoisthis wrote:
> In article<i8hlm6$fs7$>,
> victor<> 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

In message <1jpyxp8.1acm3vwngtq0sN%>, 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?

On 7/10/2010 8:48 a.m., Robert Cooze wrote:
> On 07/10/10 06:33, whoisthis wrote:
>> In article<i8hlm6$fs7$>,
>> victor<> 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."

Lawrence D'Oliveiro <_zealand> wrote:

> In message <1jpyxp8.1acm3vwngtq0sN%>, 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

In message <1jq00o2.1o68ca51unrt1kN%>, 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.

On 8/10/2010 12:15 p.m., Lawrence D'Oliveiro wrote:
> In message<1jq00o2.1o68ca51unrt1kN% .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

In message <i8llo0$8kh$>, victor wrote:

> On 8/10/2010 12:15 p.m., Lawrence D'Oliveiro wrote:
>
>> In message<1jq00o2.1o68ca51unrt1kN% .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.