Re: Dates and time zones
Re: Dates and time zones
- Subject: Re: Dates and time zones
- From: Jonathan Jackel <email@hidden>
- Date: Sat, 11 Dec 2004 21:20:06 -0500
On Dec 11, 2004, at 7:27 PM, Rory Prior wrote:
Hi,
On 11 Dec 2004, at 6:04 pm, Jonathan Jackel wrote:
*snip*
I think you may be misunderstanding the nature of an NSDate. An
NSDate represents a moment in time, with NO concept of what the time
zone is. If you do
NSDate *aDate = [[NSDate alloc]
initWithTimeIntervalSinceReferenceDate:3600];
you get an object representing a moment in time that is 1 am GMT on 1
Jan 2001, but is also 8 pm EST on 31 Dec 2000. When you do [date
description], the resulting string uses an arbitrary time zone. If I
had to guess, it would be the user's time zone, but I haven't tested
that and the docs don't say. The methods
-descriptionWithCalendarFormat:timeZone:locale: and friends exist so
you can express that moment in time as it is understood in various
time zones.
So, no, it's not retarded. But it may not be what you need.
If you create an NSDate as in your example it would use GMT as the
time zone - however if you create an NSDate with a natural language
string, like I've been doing, it happily recognises and stores /any/
time zone and will print it out in a description - however as soon as
you try and convert it into an NSCalendarDate for further processing
it suddenly loses all concept of having a time zone inside and forces
you to specify one or use GMT.
I notice your e-mail address is in the UK. Perhaps that explains your
observation.
When I create a date with [[NSDate alloc]
initWithTimeIntervalSinceReferenceDate:3600] and get its description, I
see "2000-12-31 20:00:00 -0500", in other words, 8pm in the Eastern
time zone, which is the time zone my Mac is set to use. If I do this
instead:
NSLog(@"%@", aDate);
I get "<CFDate 0x596000 [0xa01900e0]>{time = 3600}"
Which suggests that the NSDate is really a CFDate, and all it keeps
track of is the time interval -- not the time zone.
Also, the documentation says nothing about time zone behavior, so I
wouldn't count on anything beyond the fact that the NSDate represents a
point in time.
*snip*
If you want to deal with dates somewhat more conventionally, i.e.,
explicitly anchored to a particularly time zone, initialize them as
NSCalendarDates.
I would happily just use NSCalendarDate but the problem is I'm getting
my dates from external data sources so I can't guarantee the
formatting, hence my love of dateWithNaturalLanguageString. Still even
when I have the time zone information what I want to do is to convert
between hour offsets from GMT into time zone abbreviations like "EST",
"PST" and so on which NSTimeZone apparently can't do either *grumble*
So it looks like I'll have to write my own method to do this.
NSCalendarDate is a subclass of NSDate, so
dateWithNaturalLanguageString: works there as well. Then you just
setCalendarFormat: and you've got a nice looking date. I was unable to
get it to recognize a time zone abbreviation, however.
Jonathan
_______________________________________________
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