часовой пояс в си

[neon1ks]

Осенью придумал программку для определения часового пояса:

Код: (C) [Выделить]

#include <stdio.h>
#include <time.h>

int main (int argn, char *argv[]) {

int UTC;
time_t s_time, ctime1, ctime2;
struct tm * m_time;

s_time = time (NULL);

m_time = gmtime (&s_time);
ctime1 = mktime (m_time);

m_time = localtime (&s_time);
ctime2 = mktime (m_time);

UTC = (ctime2 - ctime1)/3600;
printf("UTC = %d\n", UTC);

return 0;
}
В системе менял часовой пояс и проверял, программа выдает верные результаты

Код: [Выделить]

sudo dpkg-reconfigure tzdata
Также позволяет определить часовой пояс в прошлом, например, если подставить вместо s_time = time (NULL);

Код: [Выделить]

s_time = 1410393600;Получим часовой пояс до осеннего перевода часов.

Есть еще забавная функция

Код: (C) [Выделить]

double difftime(time_t time2,time_t time1)
Во-первых, почему команда возвращает число в формате double? Когда результат всегда целое число =)
Во-вторых, в Windows данная функция не работает в MinGW.

[FixNix]

Во-первых, почему команда возвращает число в формате double? Когда результат всегда целое число =)

Функция difftime() возвращает разность в секундах между временем time1 и временем time2, то есть она возвращает величину time2— time1.
Следовательно, почему в double? - возможно, потому что дает разность с точностью до миллисекунд.

Во-вторых, в Windows данная функция не работает в MinGW.

Говорят это баг. Похоже, связанный с разрядностью. В ссылках говорится как можно обойти этот баг.

[neon1ks]

FixNix,
time_t изменяется в секундах, значит и разность тоже может быть только в секундах.

[FixNix]

neon1ks,
Да, верно. Значения в секундах. Похоже, что смысл использования double в том, что у него большой диапазон значения.

Я интересную для себя информацию нашёл, связанную с данной тематикой. Оказывается есть такая проблема как: Проблема 2038 года


Пример, показывающий сброс даты (в 03:14:08 UTC 19 января 2038 года).

Введение 64-битного формата вносит новую дату «закольцовывания» — оно произойдёт примерно через 290 миллиардов лет (в воскресенье, 4 декабря 292 277 026 596 года в 15:30:08).

[SergeyIT]

/

Я интересную для себя информацию нашёл, связанную с данной тематикой. Оказывается есть такая проблема как: Проблема 2038 года

Все новое - давно забытое старое
Проблема 2000 года
И это переживем...

[neon1ks]

SergeyIT,
Есть еще одна вещь, которую нужно учитывать
Формат времени time_t: в 32 битной системе занимает 4 байта, а в 64 битной - 8 байт. Аналогичная ситуация с форматом long.

И сейчас мне приходится, при сохранении времени в бинарный файл, время переводит в формат int. А считывать int, и затем уже переводит в формат time_t. Первоначально, просто в формате файла под время было выделено 4 байта... Так что мои программы пока имеют проблему 2038 года

FixNix,
Да, кстати, про диапазон не подумал... Это вполне может объяснить почему double.

[SergeyIT]

Есть еще одна вещь, которую нужно учитывать...
Формат времени time_t: в 32 битной системе занимает 4 байта, а в 64 битной - 8 байт.

Учитывать надо другую вещь - доживет ли программа до 2038 года

[FixNix]

SergeyIT,
И всё же, приятней осознавать, что твоя программа доживёт до 4 декабря 292 277 026 596 года 

[SergeyIT]

FixNix,

SergeyIT,
И всё же, приятней осознавать, что твоя программа доживёт до 4 декабря 292 277 026 596 года 

Особенно, если именно она станет причиной нового Большого взрыва