Ошибки в секундах NSTimeZoneFromGMTForDate?

Я пишу приложение, которое включает в себя время рождения людей, и я пытаюсь использовать IOS, чтобы получить точное смещение по Гринвичу. Я получаю явно неправильные ответы, и мне интересно, сталкивались ли с ними другие или есть ли обходные пути.

Вот код, который я использую для вычисления смещения (первая строка), и код регистрации, чтобы показать, что у меня есть.

    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);

Вот результаты - правильные для Плимута и Нью-Йорка, которые находятся по восточному времени, и смещение летнего времени верно для всех из них, но secondFromGMTForDate отличается на один час для Миннеаполиса (по центральному времени) и на час в другое направление на Атланту (по восточному времени).

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)

Любые подсказки? Что получают другие, когда пробуют Миннеаполис 26.03.70? Время Америки/Меномини определенно соответствует центральному времени, и при смещении летнего времени, равном 0, secondFromGMTForDate определенно должно быть -6 часов, а не -5.


person Apollo Grace    schedule 10.04.2015    source источник


Ответы (1)


Это правильно. Система часовых поясов Apple, как и в большинстве операционных систем, основана на данных IANA о часовых поясах. Эти данные включают в себя историческую информацию, а также текущую информацию, так что старые даты будут правильно преобразованы, даже если правила часовых поясов могут измениться.

Для America/Menominee данные включают это примечание:

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

Дата твоего испытания - 1970 год, и тогда зона была другой.

Для America/Kentucky/Monticello комментарии включают:

# 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).

Ваша тестовая дата для этой зоны — 1948 год, и похоже, что тогда это место было в центральном времени.

person Tom Harrington    schedule 10.04.2015
comment
Большое спасибо! Вот и все. Я использовал стороннюю библиотеку для поиска часовых поясов, и по какой-то причине она выдает эти странные, а не более подходящие для Миннеаполиса и Атланты. Я очень ценю ссылку IANA. Очевидно, мне нужен новый способ определения ПЗ по местоположению. - person Apollo Grace; 10.04.2015
comment
Некоторый код, который я видел, пытается найти часовой пояс, сравнивая текущее местоположение с местоположением города часового пояса. Проблема в том, что зоны имеют неправильную форму, поэтому простая близость часто неверна. - person Tom Harrington; 10.04.2015
comment
Я рассматриваю возможность использования загруженной базы данных с Geonames.org. (cities1000.txt.) В нем 144 000 городов, поэтому я должен подойти для большинства целей; а затем, в тех случаях, когда у меня есть небольшой город, которого нет в списке, я могу выполнить поиск по ближайшим широтам и долготам. Теперь мне просто нужно написать быструю программу для Mac, чтобы превратить этого зверя в управляемый sqlite-файл CoreData... - person Apollo Grace; 11.04.2015