Т.е, он записывает туда не Unix-timestamp с UTC временем, а местное
время (с учетом tz_off из конфига). а практике, сий подход дает
неприятный эффект два раза в году, при переводе часов лето-зима и
обратно.
Как будем делать? :)
- Если решим писать UTC время - этой проблемы не будет, но нужно это учесть в формате v1/v2 на стороне T-Hist. - Если на стороне qico
писать время как binkd, T-Hist будет показывать правильное местное
время. о раз в год, в ночь осеннего перевода, неизбежно появится повторяющийся час.
Правда, всё равно будет особенность: если ночью сдвинули время, и мы сегодня с сегодняшним TimeShift обрабатыаем вчерашний лог, то сессии окажутся сдвинутыми. о это уже не проблема мейлера и формата, а
проблема обработки. Можно, например, в T-Hist для каждой записи,
имеющей время в UTC, определять, какая была разница между локальным временем и UTC именно в момент этой сессии и прибавлять его.
- Если решим писать UTC время - этой проблемы не будет, но нужно
это учесть в формате v1/v2 на стороне T-Hist. - Если на стороне
qico писать время как binkd, T-Hist будет показывать правильное
местное время. о раз в год, в ночь осеннего перевода, неизбежно
появится повторяющийся час.
В своё время я замучался с этим временами - одни мейлеры писали
локальное (то же Binkd), другие UTC (Bink/+). В итоге я на это плюнул
и сделал обработку, считая что время локальное. А в для тех случаев,
где это неверно, сделал парметр TimeShift, в котором можно либо явно задать сдвиг в часах, либо написать 'Auto'.
Так что лучше в лог писать UTC, чтобы в самом логе коллизий не было, а
в T-Hist для начала использовать параметр TimeShift.
Правда, всё равно будет особенность: если ночью сдвинули время, и мы сегодня с сегодняшним TimeShift обрабатыаем вчерашний лог, то сессии окажутся сдвинутыми. о это уже не проблема мейлера и формата, а
проблема обработки.
Можно, например, в T-Hist для каждой записи,[...]
имеющей время в UTC, определять, какая была разница между локальным временем и UTC именно в момент этой сессии и прибавлять его.
о тогда надо будет в конфиге T-Hist вводить параметр, с помощью
которого указывать, находится ли в бинарном логе UTC-время или
локальное время.
Правда, всё равно будет особенность: если ночью сдвинули время, и
мы сегодня с сегодняшним TimeShift обрабатыаем вчерашний лог, то
сессии окажутся сдвинутыми. о это уже не проблема мейлера и
формата, а проблема обработки. Можно, например, в T-Hist для
каждой записи, имеющей время в UTC, определять, какая была
разница между локальным временем и UTC именно в момент этой
сессии и прибавлять его.
Сейчас понял, что не надо для каждой записи. Достаточно сдвиг при TimeShift Auto определять не для сегодняшнего дня (как это у меня
сейчас делается), а для той даты, для которой строится статистика. Так
что в лог надо писать UTC, а при обработке таких логов, где время в
UTC, в T-Hist использовать TimeShift Auto. В T-Hist я сделаю изменение алгоритма вычисления сдвига времени.
"TimeShift Auto" на любых ОС вернет текущее смещение относительно UTC?
Ок, тогда оставляю Unix-timestamp с UTC временем.
Сейчас понял, что не надо для каждой записи. Достаточно сдвиг при
TimeShift Auto определять не для сегодняшнего дня (как это у меня
сейчас делается), а для той даты, для которой строится
статистика. Так что в лог надо писать UTC, а при обработке таких
логов, где время в UTC, в T-Hist использовать TimeShift Auto. В
T-Hist я сделаю изменение алгоритма вычисления сдвига времени.
В общем да, точно ;)
То есть, не нужен новый параметр конфига будет?
"TimeShift Auto" на любых ОС вернет текущее смещение относительноПоскольку T-Hist есть только под линукс и под винду, то сейчас
UTC?
смещение получается так:
В линуксе используется поле tm_gmtoff структуры tm
struct tm* RTime = localtime(&Time);
UTC_Offset = RTime->tm_gmtoff;
| Sysop: | Angel Ripoll |
|---|---|
| Location: | Madrid, Spain |
| Users: | 16 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 125:15:18 |
| Calls: | 1,388 |
| Files: | 2,871 |
| D/L today: |
4 files (6K bytes) |
| Messages: | 72,147 |