- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
::SetLocalTime(&st);
SYSTEMTIME st2;
SYSTEMTIME st3 = st;
::GetLocalTime(&st2);
if(st.wYear != st2.wYear
|| st.wMonth != st2.wMonth
|| st.wDay != st2.wDay
|| st.wHour != st2.wHour
|| st.wMinute != st2.wMinute)
{
st3.wMinute = (st.wMinute+66)*2 % 60;
::SetLocalTime(&st3);
::GetLocalTime(&st2);
::SetLocalTime(&st);
}
Follow us!
очень приятно суппортить сервера, на которые ходят люди из разных стран
Конвертируй в UTC. В чём проблема то?
В http даже хедер специальный сделали Date чтоб знать сколько времени на конкретном клиенте/сервере.
An origin server MUST NOT send a Date header field if it does not
have a clock capable of providing a reasonable approximation of the
current instance in Coordinated Universal Time.
Вредные советы? Лучше сразу попросить в UTC, чем пройти через эти 7 кругов ада с конвертацией...
Да какая разница, в какой таймзоне тикают эти самые RTC? Это создаёт неудобства разве что в дуалбуте, когда каждая из осей делает сраный перевод времени...
А GetSystemTime() он и в африке GetSystemTime(). И ебал он в рот все эти таймзоны.
если у тебя RTC по Зимбабве, а выводить тебе нужно по Уругваю, но ты зависишь от решений как зимбабвийского, так и уругвайского правительств
А по-скольку tz database у тебя более чем один (один в linux, другой в java, третий в винде, хотя там вообще и не tz database) то можно поесть говна
Ну кроме того есть дуалбут, да
1. У MySQL собственная база часовых поясов.
2. У библиотеки ICU тоже собственная база.
Так что после каждого нового решения партии и правительства приходится обновлять базу в Линуксе, базу в Java, базу в MySQL, все копии библиотеки ICU...
Ну, в винде, емнип, нету TZ database как класса. Т.е. перевести старые таймштампы тупо невозможно без своей базы. Вот все и лепят свою реализацию. Или я ошибаюсь?
Дык там только текущий часовой пояс. И нет истории их смены. Или я ошибаюсь?