Re: NSTimeZone's localTimeZone (vs defaultTimeZone)?
Re: NSTimeZone's localTimeZone (vs defaultTimeZone)?
- Subject: Re: NSTimeZone's localTimeZone (vs defaultTimeZone)?
- From: Chris Kane <email@hidden>
- Date: Sun, 21 May 2006 14:59:10 -0700
On May 21, 2006, at 7:52 AM, email@hidden wrote:
I'm just not clear on the point of localTimeZone. Googling hasn't
shown up anything useful, although I do note that localTimeZone is
deprecated in GnuStep.
I guess my question is, what should I be using in what circumstances?
It was necessitated by NSCalendarDate.
In binding a date with a time zone, NSCalendarDate created a problem:
it often wasn't actually interesting to couple a date with a
particular time zone, but rather apply whatever time zone the machine
happened to be configured in to a date. For example, just as it is
common to want to display text strings in the user's preferred
language, so too you often want to display or compute with dates in
the machine's configured time zone, not some specific time zone.
You can do this with an NSDate + defaultTimeZone, and avoid the
binding to a specific time zone that NSCalendarDate involves. But,
there was a desire to use a single type in some circumstances (rather
than sometimes NSDate and sometimes NSCalendarDate), and a single
argument (instead of a date+timeZone pair of arguments). And,
NSCalendarDates archive themselves, so you can't just create an
NSCalendarDate with the defaultTimeZone, which works for the moment,
and then save that, because you're saving a specific time zone, and
when unarchived the NSCalendarDate would be bound to that specific
original time zone.
So the localTimeZone object had to be invented, to in some sense
break that binding that NSCalendarDate had done and restore the
abstraction of NSDate to the represented date. The localTimeZone is
a meta-time zone, basically, which represents whatever the default
time zone happens to currently be, and gets archived so that on
unarchiving the NSCalendarDate still has it's "bound to the default
time zone"-like behavior. (All the localTimeZone object does is
forward all messages to [NSTimeZone defaultTimeZone] basically.)
It seems like this could have been done other ways, too, like
defining NSCalendarDate with a nil timeZone to mean "use the
defaultTimeZone" (just like many people wish that a nil locale
dictionary meant the user's default locale dictionary). However, the
Cocoa forefathers didn't go that direction, and here we are.
Chris Kane
Cocoa Frameworks, Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden