Временные зоны и epoch

[metaclass]

Вопрос: зависит ли результат функции "вернуть количество секунд от epoch на начало сегодняшнего дня" от текущей таймзоны?
Я понял, что без поллитры вопрос таймзон, времен, календарей, а особенно хаскелевых модулей для работы с этим понять нереально.

PS: для начала сойдет:

import Data.Time.Clock
import Data.Time.Clock.POSIX

  do now<-getCurrentTime  
     let starttime = truncate $ utcTimeToPOSIXSeconds $ now {utctDayTime=0}

starttime - целое количество секунд.

Вообще говоря, я делаю либу для работы с RRDtool - она запускает исполняемый файл и кормит его командами через stdin, читая ответы через stdout. Как минимум, создать файло, заполнять его и рисовать графики оно уже умеет.

Comments

[metaclass.livejournal.com]

Оно, если по хорошему, должно единообразно работать и на линуксе и на винде.
Впрочем, какое время при этом должен показывать rrdtool, вопрос остается открытым - потому как температура на улице заметно зависит от локального времени, rrdtool внутри себя хранит все в utc, местным жителям надо показывать локальное время, а людям из других временных зон - вообще неизвестно что :)

[http://users.livejournal.com/_slw/]

оно единообразно работает в том случае, когда cmos в utc. это с виндой вроде как невозможно.

[metaclass.livejournal.com]

Ну если getCurrentTime возвращает под линуксом utc из CMOS, а под виндой корректирует его на временную зону - почему бы и нет.

[http://users.livejournal.com/_slw/]

если на винде сказали, что зона гринвич, то локальное время она будет говорить правильное, а про utc врать.

[nealar.livejournal.com]

когда cmos в utc. это с виндой вроде как невозможно
а с FBSD вроде как не нужно

[http://users.livejournal.com/_slw/]

ничего не понял.

[nealar.livejournal.com]

Из коробки на BSDшной машине CMOS не в UTC и всё работает.

[http://users.livejournal.com/_slw/]

Из коробки на BSDшной машине CMOS не в UTC

нет, разумеется.

[nealar.livejournal.com]

Так почему падвендой должно быть иначе?

[http://users.livejournal.com/_slw/]

иначе что?

[nealar.livejournal.com]

"CMOS не в UTC и не всё работает"

[http://users.livejournal.com/_slw/]

у тебя вообще какая-то каша.

[nealar.livejournal.com]

У меня, как раз всё нормально.

fbsd - CMOS не в UTC, всё работает
win - CMOS не в UTC, всё работает

[http://users.livejournal.com/_slw/]

fbsd - CMOS не в UTC


НЕТ

[nealar.livejournal.com]

Что ж тогда sysinstall задаёт вопрос "у тебя правда CMOS не в UTC?" С дефолтом именно "не в UTC"

[http://users.livejournal.com/_slw/]

вот именно, задает вопрос.

на который надо обязательно ответить.

потому что скажешь -- то и будет.

[nealar.livejournal.com]

Ну я так и говорю "да, не в UTC, в местном времени", и всё работает.

[http://users.livejournal.com/_slw/]

Ну я так и говорю "да, не в UTC, в местном времени",

каша

и всё работает.

это я вообще не понимаю к чему.

[nealar.livejournal.com]

По третьему разу повторять не буду.

[http://users.livejournal.com/_slw/]

неважно сколько раз ты разговариваешь со своими тараканами.

[nealar.livejournal.com]

с ящерицами

[victor bolshakov (from livejournal.com)]

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

[fraks-nsk.livejournal.com]

Раз уж у ребе данные - температура и давление - то логично показывать дату и время в точке измерения, и пофиг откуда там кто смотрит.

[victor bolshakov (from livejournal.com)]

нет. зайдя из, к примеру, японии я увижу, что в два часа было низкое давление - для меня это будет мои два часа, и я буду думать, сколько нужно прибавить или отнять, чтоб узнать восколько-же это было у клиента...

[fraks-nsk.livejournal.com]

Какая разница сколько времени было в Японии при измерении давления в Минске??
Кроме того, любой автоматизм определения поясного времени и процедура приведения времени к местному - возможноый источник косяков.