mktime, time_t и другие... Чего необычного?

[dememax]

Я уже писал, что занимаюсь проблемой 2038-го года. В сязи с этим вспомнил и узнал несколько забавных фактов.
Угадайте:

1. Каков диапазон целочисленных значений, который может принимать переменная типа time_t?
2. Какое значение возвращает функция mktime для идентификации ошибки?
3. Какое значение вернёт функция mktime, если передать ей отрицательный день или 14-й месяц?

Ответы:

1. Практически все целочисленные значения знакового типа; т.е. 315576000 – это 12:00:00 первого января 1980-го года по Гринвичу, а -315576000 – первое января 1960-го, и т.д.
2. Как и многие другие функции из того же набора, mktime возвращает (time_t)-1 (как ftok возращает (key_t)-1, а getsid - (pid_t)-1).
3. Для меня показалось это странным, но -2 января 1980-го или 4-ое число 14-го месяца 1990-го – то вполне нормальные значения для передачи их mktime, не будет ошибки; эта функция "трактует" эти данные логически: -2 день – это два дня назад, соответственно, 14-й месяц – это два месяца после декабря (14=12+2), т.е. февраль.

Оставляю на ваше усмотрение вопрос, что будет, если передать функции localtime значение -1.

UPD: Оказывается, в coreutils есть обработка ситуации, когда mktime возвращает значение (time_t)-1 (см. lib/parse-datetime.c):

Guard against falsely reporting errors near the time_t boundaries when parsing times in other time zones.
For example, suppose the input string "1969-12-31 23:00:00 -0100", the current time zone is 8 hours ahead of UTC, and the min time_t value is 1970-01-01 00:00:00 UTC.
Then the min localtime value is 1970-01-01 08:00:00, and mktime will therefore fail on 1969-12-31 23:00:00.
To work around the problem, set the time zone to 1 hour behind UTC temporarily by setting TZ="XXX1:00" and try mktime again.

Так же читайте в моём блоге: Критическая статья о Boost Date-Time library и std::pair vs. std::swap.

Comments

Сомтрите ИщО ою моську!

[dememax]

:-) Можете залезть в мой профайл (детали пользователя в ЖЖ), там есть "расшифровки" картинок с ссылками на большие.