6

Am I stupid? All this time I thought [NSDate date] returned the local date and time. After having some trouble with NSStringformatter/stringFromdate/dateFromString today I noticed that my [NSDate date] was returning 2011-03-06 11:00:00 +0000. After researching this I see that [NSDate date] returns a raw date which is always GMT.

What purpose does the gmt offset portion serve if it always shows +0000? Also I do not understand [myDate description]. The docs says it is supposed to display gmt offset as well as dst information. I get the same thing as [NSDate date].

Bottom line for me, if I use [NSDate date] to get the current date and it is after 2pm I get tomorrow's date as I am in the -10 time zone. Not to mention the problems I ran into today with NSDateformatter.

Am I seeing this correctly? Funny thing is I seem to remember seeing [NSDate date] returning 2011-03-06 11:00:00 -36000, or did I think I was seeing 2011-03-06 11:00:00 -10000.

I can work with it, but maybe someone can expound on this to help me better understand NSDate.

halfer
  • 19,824
  • 17
  • 99
  • 186
user278859
  • 10,379
  • 12
  • 51
  • 74
  • 1
    `+[NSDate date]` returns a date object which is autoreleased and has the current time. The reason it shows up the same as `-[NSDate description]` is that `NSLog` uses the `description` property of objects when `%@` is in use. –  Mar 07 '11 at 01:46
  • @RadekS that should be an answer. Cause it is. :) – Alex Mar 07 '11 at 01:54

2 Answers2

20

NSDate returns the current date. Though it can convert to and from string format in different locales/time zones, NSDate has no internal concept of a time zone. NSDates are not bound to any particular region. If you and anyone else in the world asked your devices to [NSDate date] simultaneously, you'd get equal results — not because it always returns in GMT but because it doesn't return in a time zone-specific manner. In Cocoa, a date is a specific moment in the history of the Earth. How you write a date is related to your calendar, your time zone and your locale.

You aren't getting tomorrow's date, you're getting the correct date and then noticing it gives a different day if expressed in GMT. It's the correct date, just written differently from what you'd like.

'description' is a method overridden from NSObject. When you NSLog an object, what happens internally is that the description method is called and the string returned is printed. So you should get identical results from logging object and [object description], since the former calls description and prints that string, the latter calls description then calls description on the resulting string and prints that. NSStrings return themselves as the result of description.

It should be the default behaviour but to get a meaningful description, try:

NSLog(@"%@", [[NSDate date] descriptionWithCalendarFormat:nil 
           timeZone:[NSTimeZone localTimeZone] locale:[NSLocale currentLocale]]);

If that still logs in GMT then your device believes itself to be in GMT. I've no idea how reliable the simulator is about that sort of thing.

Tommy
  • 99,986
  • 12
  • 185
  • 204
  • Tommy, thanks. That was very helpful. With regard to your statement about it giving me tomorrows date. I see your point but for me I was expecting to be getting the date in my time zone (local date and time) so to me it is tomorrows date. I think this is just a case of semantics but for all intents and purposes doesn't [NSDate date] return GMT since GMT is the zero time zone. Great answer - thanks. – user278859 Mar 07 '11 at 05:16
  • Would you mind answering one more question? I am having trouble understanding what the documentation says about [NSTimeZone localTimeZone]. It says that it "Returns an object that forwards all messages to the default time zone for the current application". What does that mean. To me it implies that calling it somehow affects subsequent operations with dates or times. Thanks. – user278859 Mar 07 '11 at 05:21
  • I think the slightly roundabout wording is just because the object returned by localTimeZone remains semantically correct even if the time zone changes, whereas defaultTimeZone doesn't. So the first object appears to update itself automatically, but the second doesn't. Which internally is an extra level of indirection, but it does feel like they've probably told us more than we need to know about the implementation there. – Tommy Mar 07 '11 at 10:45
  • Tommy, again thanks. That really helped demystify both localTimeZone and defaultTimeZone for me. – user278859 Mar 07 '11 at 16:37
  • I would vote this answer up if it clarified the difference between UTC and GMT. They are not the same. UTC is what is returned from [NSDate date]. GMT will calculate DST so the time will change depending on the time of year. Beware it can affect some date comparisons. – Jim Aug 24 '12 at 15:30
  • @Jim GMT doesn't include daylight savings; Britain switches from GMT to BST. To quote wikipedia (being right for once): "For most common purposes, UTC is synonymous with GMT, but GMT is no longer precisely defined by the scientific community". `NSDate` doesn't return in GMT or in any other time zone; it's time zone agnostic. Running the code I've provided once with 'GMT' and once with 'BST' produces different times. – Tommy Aug 24 '12 at 19:48
  • 2
    I'd like to point out that since OSX 10.10, the method `- descriptionWithCalendarFormat:timeZone:locale:` has been removed. – NSNoob Oct 29 '15 at 10:36
-1

In Swift:

NSDate() gives us an agnostic date's description, it always returns the UTC+0 date time, independently of the device's time zone:

print(NSDate())

.descriptionWithLocale(NSLocale.currentLocale())! gives us a localized date's description UTC+N date time where N represents the offset (positive or negative) between UTC+0 and the current local date time:

print(NSDate().descriptionWithLocale(NSLocale.currentLocale())!)
King-Wizard
  • 15,628
  • 6
  • 82
  • 76