Apple’s iThings Fail Daylight Saving

Discussion in 'NZ Computing' started by Lawrence D'Oliveiro, Oct 6, 2010.

  1. <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?
    Lawrence D'Oliveiro, Oct 6, 2010
    #1
    1. Advertising

  2. Lawrence D'Oliveiro

    victor Guest

    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.
    victor, Oct 6, 2010
    #2
    1. Advertising

  3. Lawrence D'Oliveiro

    David Empson Guest

    Re: Apple's iThings Fail Daylight Saving

    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
    David Empson, Oct 6, 2010
    #3
  4. Lawrence D'Oliveiro

    Enkidu Guest

    Re: Apple’s iThings Fail Daylight Saving

    On 07/10/10 06:33, whoisthis wrote:
    > In article<i8hlm6$fs7$-september.org>,
    > 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
    Enkidu, Oct 6, 2010
    #4
  5. Re: Apple's iThings Fail Daylight Saving

    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?
    Lawrence D'Oliveiro, Oct 7, 2010
    #5
  6. Lawrence D'Oliveiro

    victor Guest

    Re: Apple’s iThings Fail Daylight Saving

    On 7/10/2010 8:48 a.m., Robert Cooze wrote:
    > On 07/10/10 06:33, whoisthis wrote:
    >> In article<i8hlm6$fs7$-september.org>,
    >> 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."
    victor, Oct 7, 2010
    #6
  7. Lawrence D'Oliveiro

    David Empson Guest

    Re: Apple's iThings Fail Daylight Saving

    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
    David Empson, Oct 7, 2010
    #7
  8. Re: Apple's iThings Fail Daylight Saving

    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.
    Lawrence D'Oliveiro, Oct 8, 2010
    #8
  9. Lawrence D'Oliveiro

    victor Guest

    Re: Apple's iThings Fail Daylight Saving

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


    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
    victor, Oct 8, 2010
    #9
  10. Re: Apple's iThings Fail Daylight Saving

    In message <i8llo0$8kh$-september.org>, victor wrote:

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

    >
    > 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.
    Lawrence D'Oliveiro, Oct 8, 2010
    #10
  11. Lawrence D'Oliveiro

    victor Guest

    Re: Apple's iThings Fail Daylight Saving

    On 8/10/2010 12:47 p.m., Lawrence D'Oliveiro wrote:
    > In message<i8llo0$8kh$-september.org>, victor wrote:
    >
    >> On 8/10/2010 12:15 p.m., Lawrence D'Oliveiro wrote:
    >>
    >>> 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.

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


    Still dependent on the tzdata being correct, its been wrong in linux
    distros for NZ before.
    victor, Oct 8, 2010
    #11
  12. Lawrence D'Oliveiro

    Dave Doe Guest

    Re: Apple's iThings Fail Daylight Saving

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


    Do you (or anyone else) have problems with calender syncing creating
    duplicate appointments? I haven't totally sussed it - except to say
    that Vodafone and Apple NZ have both said the problem will fix itself in
    Nov 27 (when the iOS 4.2 update is released).

    My problem is this... I host mail for some folk - so that they can get
    "push" mail, Calendar, Contacts and Tasks (no Tasks in the iPhone).
    It's on Exchange Server - but that's not the problem. The folks with
    HTC Touch Pro 2 phones are fine. The iPhone folk (since the iOS 4.1
    update) all now have duplicate Calendar items.

    I can't find any interim way to fix it.

    Worse, I don't charge 'em for this - nor any problems that arise - it's
    a real PITA at the moment for me. I've spent a bit of time on it, to no
    avail.


    --
    Duncan.
    Dave Doe, Oct 8, 2010
    #12
  13. Re: Apple's iThings Fail Daylight Saving

    In message <i8lnpl$lno$-september.org>, victor wrote:

    > Still dependent on the tzdata being correct, its been wrong in linux
    > distros for NZ before.


    When? It gets updated about half a dozen times a year. Whenever any rule
    changes anywhere in the world, the Olson database is pretty much the first
    place it will appear.
    Lawrence D'Oliveiro, Oct 8, 2010
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rob J

    Nokia PC Sync daylight saving problem

    Rob J, Feb 6, 2006, in forum: NZ Computing
    Replies:
    2
    Views:
    399
    Peter S
    Feb 7, 2006
  2. Matty F
    Replies:
    25
    Views:
    649
    Lawrence D'Oliveiro
    Nov 3, 2006
  3. Lawrence D'Oliveiro

    NZ daylight saving change

    Lawrence D'Oliveiro, Aug 10, 2007, in forum: NZ Computing
    Replies:
    28
    Views:
    838
    Lawrence D'Oliveiro
    Aug 15, 2007
  4. Lawrence D'Oliveiro

    Re: Daylight Saving

    Lawrence D'Oliveiro, Sep 22, 2007, in forum: NZ Computing
    Replies:
    40
    Views:
    1,098
    Lawrence D'Oliveiro
    Sep 30, 2007
  5. David Empson

    Daylight Saving patch for New Zealand

    David Empson, Sep 27, 2007, in forum: NZ Computing
    Replies:
    2
    Views:
    416
    David Empson
    Sep 27, 2007
Loading...

Share This Page