2

I'm writing an application that involves people's birth times, and I'm attempting to use IOS to get the accurate GMT offset. I'm getting what are clearly wrong answers, and I wonder whether others have encountered them, or if there are any workarounds.

Here's the code I'm using to compute the offset (first line), and the logging code to show what I've got.

    ret.dateTime.offset = [tz secondsFromGMTForDate:date] / 3600.0;
    double dstOffset = [tz daylightSavingTimeOffsetForDate:date] / 3600.0;
    NSLog(@"Setting offset for %@ on %@, to %3.1f", ret.location.description, ret.dateTime.briefDateDescription, ret.dateTime.offset);
    NSLog (@"  (TZ Name = %@, date = %@, dstOffset = %3.1f)", tz.name, date, dstOffset);

Here are the results - correct for Plymouth and New York, which are in Eastern time, and the DST offset is correct for all of them, but secondsFromGMTForDate is off by one hour for Minneapolis (in Central time), and off by an hour in the other direction for Atlanta (in Eastern time).

Setting offset for Minneapolis, MN on 3/26/70, to -5.0
  (TZ Name = America/Menominee, date = 1970-03-26 14:29:00 +0000, dstOffset = 0.0)
Setting offset for Plymouth, MA on 1/13/80, to -5.0
  (TZ Name = America/New_York, date = 1980-01-14 02:52:00 +0000, dstOffset = 0.0)
Setting offset for Atlanta, GA on 10/10/48, to -6.0
  (TZ Name = America/Kentucky/Monticello, date = 1948-10-10 13:07:00 +0000, dstOffset = 0.0)
Setting offset for New York, NY on 6/11/80, to -4.0
  (TZ Name = America/New_York, date = 1980-06-11 12:25:00 +0000, dstOffset = 1.0)

Any clues? What do others get when they try Minneapolis on 3/26/70? America/Menominee is definitely central time, and with a DST Offset of 0, the secondsFromGMTForDate should definitely be -6 hours, not -5.

Apollo Grace
  • 361
  • 3
  • 16

1 Answers1

4

These are correct. Apple's time zone system, as with most operating systems, is based on the IANA time zone data. That data includes historical information as well as current information, so that old dates will convert correctly even though time zone rules can change.

For America/Menominee, the data includes this note:

# Dickinson, Gogebic, Iron, and Menominee Counties, Michigan,
# switched from EST to CST/CDT in 1973.

Your test date is in 1970, and the zone was different then.

For America/Kentucky/Monticello the comments include:

# After prolonged debate, and despite continuing deep differences of opinion,
# Wayne County (central Kentucky) is switching from Central (-0600) to Eastern
# (-0500) time.  They won't "fall back" this year.  See Sara Shipley,
# The difference an hour makes, Nando Times (2000-08-29 15:33 -0400).

Your test date for this zone is in 1948, and it looks like that location was in central time then.

Tom Harrington
  • 69,312
  • 10
  • 146
  • 170
  • Thank you so much! That's it. I've been using a third-party library to look up time zones, and for some reason it's coming up with these weird ones rather than the more suitable ones for Minneapolis and Atlanta. I really appreciate the IANA link. Clearly I need a new way to determine a TZ from a location. – Apollo Grace Apr 10 '15 at 17:03
  • Some code I've seen attempts to find a time zone by comparing the current location to time zone city locations. The problem is, zones have irregular shapes, so simple proximity is frequently wrong. – Tom Harrington Apr 10 '15 at 17:13
  • I'm looking at using a downloaded database from Geonames.org. (cities1000.txt.) It's got 144,000 cities, so I should be good for most uses; and then in cases where I have a small town that isn't in the list, I can search on nearby latitudes & longitudes. Now I just have to write a quick Mac program to turn this beast into a manageable CoreData sqlite file... – Apollo Grace Apr 11 '15 at 00:46