Basil A. SidorovУ любого варианта со смещением есть фундаментальный изъян: невозможно корректно сдвинуть отметку по временнОй шкале. Для такого сдвига требуется (именованный) часовой пояс. Ну и умение работать с
базой часовых поясов .
Ну да, и в советах по постгресу парень так и советует. Но это вполне можно даже зашить внутрь клиентской библиотеки. По крайней мере, проблемы варианта со смещением решаемы, а в ряде случаев даже вовсе отпадают за счет неиспользования таймзон и поголовного хранения в utc. Вариант же без смещения вообще слаб без привязки к локали. Это как строка без кодировки: вроде бы что-то внутри есть, но осмысленные данные достать затруднительно.
P.S. HTTP, таки - без смещения:
Твоя правда, попутал с XML датой.
Кто-нибудь может точно сказать сколько времени будет в Москве ровно через 2 года?
Сколько будет в Лондоне сказать можно. А вот сколько будет в Москве - зависит от того будет ли через два года осуществляться перевод часов на летнее время, или нет. А это политический вопрос.
Сколько будет в Лондоне, сказать нельзя. Может, будет сдвиг тектонических плит, и UK переплывет в пояс GMT-1 :). И точно так же нельзя сказать про любую таймзону любой страны. Даже сама шкала UTC и то не является строго последовательной. Т.ч. с 100% надежностью можно рассчитывать интервалы только между датами в прошлом.
1. Хранить всё в UTC (имхо без смещения, т.е. в UTC+0).
Имхо, перебор. Хотя пока не могу придумать пример необходимости хранения смещения.
2. Уметь задавать пояс сервера
Зачем? Чтобы опять иметь гемор со сменами поясов или летним временем, как в начале топика? Да еще и плодить сущности: тут у нас в конфиге +3, вон там - +3.5, а тут +4, это типа летнее время, но зимой я забыл обновить конфиг.
3. Уметь отдавать время с сервера клиенту в удобной ему зоне. Разработчику порограммы может быть удобно:
a) Видеть всё только в зоне сервера.
б) Видеть всё только в зоне своей ОС.
в) Видеть всё в указанной самим клиентом зоне (естественно что на каждый коннект она может быть своя).
г) Иметь возможность менять рабочую зону без переконнекта.
д) Иметь возможность указывать рабочую зону для конкретного запроса.
а - Зачем?
б, в, г, д - разумеется.
4. Правильно обрабатывать запросы типа:
- ... where TimeStampField >= CURRENT_DATE(CLIENT_ZONE) -- чтобы получить записи за клиентское сегодня (клиентский пояс указывается в пункте 3)
- ... where TimeStampField >= CURRENT_DATE(SERVER_ZONE) -- чтобы получить записи за серверное сегодня (серверный пояс указывается в пункте 2)
- ... where TimeStampField >= CURRENT_DATE(+3) -- чтобы получить записи за (UTC+3)-шное сегодня.
1 - можно делать по умолчанию при получении типа timestamp (в случае, если по примеру Постгреса добавлять тип timestampTZ, а не заменять timestamp)
2 - в 3й раз, зачем?
3 - разумеется; только вот, имхо, надо заранее и жестко обрубить возможность задавать смещение числом. Потому что это сегодня +3. А завтра будет +4. А сегодня, но в соседнем городе, куда прогу перенесли на флешке, - +5.
