Re: разработка API для просмотра IPTV сервиса Rodnoe.TV (обсуждение/предложения)

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


Т.е. возьмем к примеру одну передачу из ЕПГ.

Она начинается теплым майским днем (например 1 мая ) в 12:00 по Москве. Часовой пояс +3.

Клиент сидит во Франкфурте в часовом поясе +1 ну и еще +1 час летнего временного сдвига, итого = +2 часа (что у него в аккаунте и занесено: "зона +1", "учитывать летний сдвиг" ).

Я хочу вернуть время ее начала уже готовое КЛИЕНТСКОЕ, взяв клиентские настройки из базы.

Как я это сделаю в случае строкового времени

Возьму время начала передачи, приведенное к Гринвичу (UTC|GMT),

получаем 9:00 UTC

добавлю таймзону клиента и его летний сдвиг времени.

получаем 11:00 .

Итого:
в базе в ЕПГ "2011-05-01 12:00:00"
клиенту отдано строковое "2011-05-01 11:00:00"
Никаких коррекций от клиентской части не требуется, возможность ошибок минимальна


Вариант таймстампа
Ну все то же что и для строкового.
Дополнительно надо упаковать дату в юникстайм.

Если делать это стандартными средствами, то получим юникстайм с учетом серверной таймзоны.

Допустим сервер находится в часовом поясе +4 без летнего времени (это для наглядности, вообще-то неважно, пусть даже в зоне UTC).

Если я тупо конвертну стандартным например php::time() либо postgresql::extract_epoch(), то получу не количество секунд в разнице "2011-05-01 11:00:00" - "1970-01-01 00:00:00", а количество секунд от этой разницы да еще минус секунды таймзоны и летнего сдвига (в данном случае - 3600*4).

Т.е. при обратной конвертации в строку (а это необходимо) клиентское приложение должно учесть таймзону с которой происходила упаковка, иначе клиент получит "2011-05-01 09:00:00"

Итого:
в базе в ЕПГ "2011-05-01 12:00:00"
клиенту отдано вместо строкового "2011-05-01 11:00:00" интовое, конвертируемое в "2011-05-01 09:00:00"

ВЫХОД

1) использовать в АПИ только строковое представление дат.

2) паковать в юникстайм не клиентское время а его "отражение на UTC", т.е. в нашем примере не "2011-05-01 11:00:00" а "2011-05-01 09:00:00" ("2011-05-01 11:00:00" минус 2 часа таймзоны).
Тогда распаковщик учтет таймзону на клиенте (вы сможете в приставках или программах ее получать? Или опять же будете тащить ее из базы?) и распакует ее в строку "2011-05-01 11:00:00" (т.е. в то что нужно, но это путь "через горы и леса и еще немножко полем&quot
Но SERVERTIME в ответе так отдавать бессмісленно.

Re: разработка API для просмотра IPTV сервиса Rodnoe.TV (обсуждение/предложения)

А может так - всё в таймстампах по UTC, и добавить в хэдер что-то типа clientOffset = "7200" Этот оффсет - часовая зона + летний сдвиг. Помоему однозначней некуда.

Re: разработка API для просмотра IPTV сервиса Rodnoe.TV (обсуждение/предложения)

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

Re: разработка API для просмотра IPTV сервиса Rodnoe.TV (обсуждение/предложения)

сделайте два поля:
одно в виде unixtime в UTC, второе в виде тектовой интерпретации даты-времени с учетом локальных настроек пользователя. и будет всем счастье

Re: разработка API для просмотра IPTV сервиса Rodnoe.TV (обсуждение/предложения)

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

Re: разработка API для просмотра IPTV сервиса Rodnoe.TV (обсуждение/предложения)

[quote author=nitrogen14 link=topic=7681.msg114086#msg114086 date=1302194190]
ничерта не понимаю, что за изобретение велосипеда?
я просто в шоке. сделайте как у картины и не парьтесь.
чем дальше, тем ужаснее идеи
[/quote]
Почему велосипеда? время по гмт - стандарт. А клиентский сдвиг - чтобы настройки на сервере перенимать, а не локально мудрить с зоной.
Хотя если будет "как у картины" - я только за.

Re: разработка API для просмотра IPTV сервиса Rodnoe.TV (обсуждение/предложения)

Было бы не плохо отдавать таймстамп без всяких корекций, т.е. просто отдавать php::time(), зону из приставки заберем Чтоб уже ничего не менялось лишний раз.
Ну а строковое пусть будет как угодно, наверно для клиента типа "вебморда" это лучше

Re: разработка API для просмотра IPTV сервиса Rodnoe.TV (обсуждение/предложения)

Поддерживаю Eugene Bond

[quote author=Eugene Bond link=topic=7681.msg114089#msg114089 date=1302194343]
сделайте два поля:
одно в виде unixtime в UTC, второе в виде тектовой интерпретации даты-времени с учетом локальных настроек пользователя. и будет всем счастье
[/quote]

Поддерживаю Stalker

[quote author=Stalker link=topic=7681.msg114093#msg114093 date=1302195135]
Хотя если будет "как у картины" - я только за.
[/quote]

Не поддерживаю technic

[quote author=technic link=topic=7681.msg114113#msg114113 date=1302198509]
Было бы не плохо отдавать таймстамп без всяких корекций, т.е. просто отдавать php::time(), зону из приставки заберем
[/quote]

Re: разработка API для просмотра IPTV сервиса Rodnoe.TV (обсуждение/предложения)

Мне всегда казалось, что "как у картины" это и есть без всяких коррекций ?!

Re: разработка API для просмотра IPTV сервиса Rodnoe.TV (обсуждение/предложения)

сервертайм или вообще о времени речь?

Re: разработка API для просмотра IPTV сервиса Rodnoe.TV (обсуждение/предложения)

а давайте сделаем проще
перейдем на язык цифр - он однозначнее.

у нас есть два разных времени: ЕПГ и сервертайм

возьмем несколько значений:

часовой пояс сервера: "03:00:00"
локальное время на сервере: 2011-05-07 09:00:00

часовой пояс клиента: "-01:00:00"
локальное ( в клиентском часовом поясе) время начала передачи: 2011-05-08 11:00:00

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

всего лишь две цифры
и я тогда однозначно пойму что вы хотите получить

Re: разработка API для просмотра IPTV сервиса Rodnoe.TV (обсуждение/предложения)

хм..
видимо что-то такое:

с другой стороны, фактически получаем дублирование информации. поэтому можно попробовать оставить текущие таймстампы как есть (с учетом поправки часовых поясов у сервера и пользователя), а текстовые выдавать по ISO как в примере.
будет и обратная совместимость и однозначная информативность

Re: разработка API для просмотра IPTV сервиса Rodnoe.TV (обсуждение/предложения)

epg_start: 1304852400
servertime: 1304830800

Re: разработка API для просмотра IPTV сервиса Rodnoe.TV (обсуждение/предложения)

[quote author=Eugene Bond link=topic=7681.msg114573#msg114573 date=1302540846]
<servertime>2011-05-07T06:00:00+03</servertime>
..
<epg_start>2011-05-08T12:00:00-01</epg_start>
[/quote]
естественно правильные значения в примере 2011-05-07Т09:00:00+03 и 2011-05-08T11:00:00-01

Re: разработка API для просмотра IPTV сервиса Rodnoe.TV (обсуждение/предложения)

Идём например вот сюда http://www.timestampgenerator.com/

И делаем столько таймстампов, сколько хочеться.