metaclass: (Default)
[personal profile] metaclass
Скажите мне пожалуйста, существует ли общепринятый метод передачи дат или даты-времени в параметрах URL для сервиса, например?
Сколько не пишу подобное - практически всегда все сводится к "прибиваем гвоздями ISO8601, парсим строку руками и под каждую задачу заново решаем, что делать с невалидными строками - то ли валится с 4хх, то ли валится с 5хх, то ли игнорировать ошибки, использовать или нет TryParse (если он вообще есть, обычно нету - "у нас всегда все работает, а невалидных дат не бывает") и как возвращать сообщения об ошибках клиенту так, чтобы он мог хоть что-то вменяемое сделать.

Date: 2013-10-13 12:19 pm (UTC)
From: [identity profile] sergiej.livejournal.com
если юзеру нет дела до даты и времени то юниксовый таймстемп просто и удобно. Если есть дело то хоть и не станарт, но удобоно: YYYYMMDDHHMMSS (ну если часовой пояс некритичен) :)
Edited Date: 2013-10-13 12:20 pm (UTC)

Date: 2013-10-13 12:31 pm (UTC)
From: [identity profile] belezbar.livejournal.com
А если ещё и пояс добавить: 13 = +3, 03 = -3 ?

Date: 2013-10-13 12:51 pm (UTC)
From: [identity profile] sergiej.livejournal.com
можно, но как автор правильно заметил - всё это обходные маневры, а стандарта безопасного нет

Date: 2013-10-13 04:35 pm (UTC)
From: [identity profile] dr-cha0s.livejournal.com
Зачем? Всё в UTC.

Date: 2013-10-13 12:53 pm (UTC)
From: [identity profile] gds.livejournal.com
во, такое я видел, вполне удобно.

А ошибки парсинга -- ну, как и в любых других случаях обрабатывать, чем дата/время тут особенны?

Date: 2013-10-13 02:28 pm (UTC)
From: [identity profile] w00dy.livejournal.com
А если вам нужны даты до 1970 года? В общем в жопу unix timestamp. Лучше тогда как в DateTime - хранить тики в int64, один тик - 100ns. До 10000 года вроде хватает.

Date: 2013-10-13 03:19 pm (UTC)
From: [identity profile] sergiej.livejournal.com
Можно тики. Но как тогда даты до большого взрыва хранить? И непонятно как время из параллельного пространства хранить.

Date: 2013-10-13 03:41 pm (UTC)
From: [identity profile] sbj-ss.livejournal.com
Зря вы так категорично.
Точек отсчёта придумано стопицот, но на моей памяти ни одна не учитывает интересы историков. Когда несколько лет назад у нас на конторе зашла речь об обучающей системе именно по истории, то вообще предлагалась безумная идея собственного формата с распихиванием по битам (чтобы влезть в 4 байта на x86), который в SQL Server хранился просто в int - чтобы обеспечить поиск и сортировку. Это не от хорошей жизни, а от отсутствия альтернатив.
Впрочем, "даты до 1970" касаются не только историков. Даты рождения, например.

Date: 2013-10-13 04:35 pm (UTC)
From: [identity profile] sergiej.livejournal.com
я просто шучу. Всё зависит от поставленной задачи.

Date: 2013-10-13 10:29 pm (UTC)
From: [identity profile] lionet.livejournal.com
Что не так с юниксовым таймстампом для дней рождения? Отрицательные числа — не миф.

Date: 2013-10-14 08:39 am (UTC)
From: [identity profile] sbj-ss.livejournal.com
Да, по стандарту - timestamp со знаком. Спасибо, что поправили.

Date: 2013-10-13 10:31 pm (UTC)
From: [identity profile] lionet.livejournal.com
YYMMDDHHMMSS — это и есть один вариантов ISO8601. Только если добавить в конец символ 'Z' — будет ещё и однозначно в смысле таймзоны: UTC.

Date: 2013-10-14 04:25 am (UTC)
From: [identity profile] sergiej.livejournal.com
ну вот и прелестно. Главное, что оно парсится в лёт стандартными парсерами дат в джаве например.

Profile

metaclass: (Default)
metaclass

April 2017

S M T W T F S
      1
2345678
9101112 131415
16171819202122
23242526272829
30      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 2nd, 2025 07:38 pm
Powered by Dreamwidth Studios