NSDatePicker weirdness with time.

  • In my app I have:

    [NSTimeZone setDefaultTimeZone:[NSTimeZone
    timeZoneWithAbbreviation:@"GMT"]];        // So that when we decode NSDate
    objects, we get the h/m/s as GMT

    I also have an NSDatePicker set to only show the hh:mm

    My system clock is set to US West Coast Time and US format.

    When I highlight the HH field and type a "5", a "9" shows up in the hour
    field.

    When I type a "1", the 1 shows up for about 1 second, then changes to a 5.

    When I type a "2", I get a "6".

    It seems to be adding 4 hours to what I type.

    What is going on here?

    Trygve
  • Trygve,

    That should work. I suspect that you are setting the timeZone of the NSDatePicker as well. There is a bug, where is you set the NSDatePicker timeZone but do not set the calendar, then you will run into this problem. (Same thing with NSDatePicker locale.)

    So, either don't adjust the NSDatePicker defaults, or set a calendar for the NSDatePicker.

    -raleigh

    On Jul 5, 2011, at 4:09 PM, Trygve Inda wrote:

    > In my app I have:
    >
    >
    > [NSTimeZone setDefaultTimeZone:[NSTimeZone
    > timeZoneWithAbbreviation:@"GMT"]];        // So that when we decode NSDate
    > objects, we get the h/m/s as GMT
    >
    >
    > I also have an NSDatePicker set to only show the hh:mm
    >
    > My system clock is set to US West Coast Time and US format.
    >
    > When I highlight the HH field and type a "5", a "9" shows up in the hour
    > field.
    >
    > When I type a "1", the 1 shows up for about 1 second, then changes to a 5.
    >
    > When I type a "2", I get a "6".
    >
    > It seems to be adding 4 hours to what I type.
    >
    > What is going on here?
    >
    > Trygve
  • > Trygve,
    >
    > That should work. I suspect that you are setting the timeZone of the
    > NSDatePicker as well. There is a bug, where is you set the NSDatePicker
    > timeZone but do not set the calendar, then you will run into this problem.
    > (Same thing with NSDatePicker locale.)
    >
    > So, either don't adjust the NSDatePicker defaults, or set a calendar for the
    > NSDatePicker.
    >
    > -raleigh
    >

    It seems that NSDateFormatters instantiated in my nibs get their zone set to
    PDT (because of my time settings), despite having called

    [NSTimeZone setDefaultTimeZone:[NSTimeZone
    timeZoneWithAbbreviation:@"GMT"]];

    Before any nibs are loaded.

    Formatters created in code with:

    [[[NSDateFormatter alloc] init] autorelease];

    Have the zone set to GMT as specified in setDefaultTimeZone

    Seems like an OS bug to me.

    T.
  • On 6 Jul 2011, at 12:16 AM, Trygve Inda wrote:

    > It seems that NSDateFormatters instantiated in my nibs get their zone set to
    > PDT (because of my time settings), despite having called
    >
    > [NSTimeZone setDefaultTimeZone:[NSTimeZone
    > timeZoneWithAbbreviation:@"GMT"]];
    >
    > Before any nibs are loaded.

    Which makes sense. The model is that objects in XIBs/NIBs are instantiated when Interface Builder archives them, not when the NIBs are loaded. Your attempt to initialize them from a runtime default has no effect because they've already been initialized.

    — F
  • On Wed, Jul 6, 2011 at 7:11 AM, Fritz Anderson <fritza...> wrote:
    > On 6 Jul 2011, at 12:16 AM, Trygve Inda wrote:
    >
    >> It seems that NSDateFormatters instantiated in my nibs get their zone set to
    >> PDT (because of my time settings), despite having called
    >>
    >> [NSTimeZone setDefaultTimeZone:[NSTimeZone
    >> timeZoneWithAbbreviation:@"GMT"]];
    >>
    >> Before any nibs are loaded.
    >
    > Which makes sense. The model is that objects in XIBs/NIBs are instantiated when Interface Builder archives them, not when the NIBs are loaded. Your attempt to initialize them from a runtime default has no effect because they've already been initialized.

    Well, it "makes sense" insofar as "this is a plausible explanation for
    this behavior." But it would make much more sense for NSDateFormatter
    to implement -awakeFromNib and configure itself according to the
    locale it's loaded into.

    --Kyle Sluder
  • This conversation started about NSDatePicker. Now you are referring to NSDateFormatter. Which one are you dealing with? My test shows that a nib instantiated NSDatePicker has a nil timeZone value.

    -raleigh

    On Jul 6, 2011, at 8:05 AM, Kyle Sluder wrote:

    > On Wed, Jul 6, 2011 at 7:11 AM, Fritz Anderson <fritza...> wrote:
    >> On 6 Jul 2011, at 12:16 AM, Trygve Inda wrote:
    >>
    >>> It seems that NSDateFormatters instantiated in my nibs get their zone set to
    >>> PDT (because of my time settings), despite having called
    >>>
    >>> [NSTimeZone setDefaultTimeZone:[NSTimeZone
    >>> timeZoneWithAbbreviation:@"GMT"]];
    >>>
    >>> Before any nibs are loaded.
    >>
    >> Which makes sense. The model is that objects in XIBs/NIBs are instantiated when Interface Builder archives them, not when the NIBs are loaded. Your attempt to initialize them from a runtime default has no effect because they've already been initialized.
    >
    > Well, it "makes sense" insofar as "this is a plausible explanation for
    > this behavior." But it would make much more sense for NSDateFormatter
    > to implement -awakeFromNib and configure itself according to the
    > locale it's loaded into.
    >
    > --Kyle Sluder
  • > On Wed, Jul 6, 2011 at 7:11 AM, Fritz Anderson <fritza...>
    > wrote:
    >> On 6 Jul 2011, at 12:16 AM, Trygve Inda wrote:
    >>
    >>> It seems that NSDateFormatters instantiated in my nibs get their zone set to
    >>> PDT (because of my time settings), despite having called
    >>>
    >>> [NSTimeZone setDefaultTimeZone:[NSTimeZone
    >>> timeZoneWithAbbreviation:@"GMT"]];
    >>>
    >>> Before any nibs are loaded.
    >>
    >> Which makes sense. The model is that objects in XIBs/NIBs are instantiated
    >> when Interface Builder archives them, not when the NIBs are loaded. Your
    >> attempt to initialize them from a runtime default has no effect because
    >> they've already been initialized.
    >
    > Well, it "makes sense" insofar as "this is a plausible explanation for
    > this behavior." But it would make much more sense for NSDateFormatter
    > to implement -awakeFromNib and configure itself according to the
    > locale it's loaded into.
    >

    Exactly.

    I have worked around it of course, but there is no logical reason for the
    date/time controls to not configure themselves based on the locale.

    T.
  • On Wed, 6 Jul 2011 18:46:54 -0700, Trygve Inda said:

    > I have worked around it of course, but there is no logical reason for the
    > date/time controls to not configure themselves based on the locale.

    Usually, but not always.  In some cases, one might want a date picker to always use ISO 8601, regardless of user preference.

    --
    ____________________________________________________________
    Sean McBride, B. Eng                <sean...>
    Rogue Research                        www.rogue-research.com
    Mac Software Developer              Montréal, Québec, Canada
previous month july 2011 next month
MTWTFSS
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Go to today