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

Date: 2013-10-13 12:16 pm (UTC)
From: [identity profile] veremeenko-alex.livejournal.com
Нету. Все во что кто горазд.

И не дай бог контрол на странице использует локаль пользователя, а парсится с локалью сервера.
Сайт нормально работает только до 12 числа каждого месяца :)

Date: 2013-10-13 12:26 pm (UTC)
From: [identity profile] falcrum.livejournal.com
Потом месяц 13-й появляется? А что до этого херню сохраняет - никого не настораживает?

Date: 2013-10-13 02:35 pm (UTC)
From: [identity profile] veremeenko-alex.livejournal.com
Так для америкосов все ок, а то что этот же сайт плохо работает у других, nobody care.
Понятно что для сайта лечится просто -показываем в локали пользователя, но везде работаем и храним в локали сервера.
Но для рестфул сервиса или сайта с внешним апи пляски обеспечены.

Date: 2013-10-13 02:24 pm (UTC)
From: [identity profile] w00dy.livejournal.com
вот-вот, ебантеи. Вместо этого сранного html5 лучше бы сделали кошерную поддержку глобализации.

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
ну вот и прелестно. Главное, что оно парсится в лёт стандартными парсерами дат в джаве например.

Date: 2013-10-13 12:31 pm (UTC)
From: [identity profile] mehanizator.livejournal.com
таймстамп GMT+0

Date: 2013-10-13 12:41 pm (UTC)
From: [identity profile] metaclass.livejournal.com
В секундах, микросекундах, начиная от какой даты отсчет? :)
И как представлять величины типа "учетная дата" (у нее времени нет, соотвественно, представление с секундами для нее противоречиво")

Date: 2013-10-13 01:46 pm (UTC)
From: [identity profile] thedeemon.livejournal.com
В 100-наносекундных юнитах от первого явления ангела Джабраила пророку Мухаммеду.

Date: 2013-10-13 02:20 pm (UTC)
From: [identity profile] theiced.livejournal.com
время - когда это время события или чего то ещё - таймстэмп, юниксовый. дату - если это бухгалтерская дата - ymd. если кто то передаёт ydm или ещё какой ад - это его проблемы же.

Date: 2013-10-13 02:21 pm (UTC)
From: [identity profile] theiced.livejournal.com
ну или передай как три поля - если не хочешь что бы ошибки проникали такие, пооохуй.

Date: 2013-10-14 07:32 am (UTC)
From: [identity profile] david-m.livejournal.com
Ну так это (даты) и есть единственная реальная проблема. Потому что в разных поясах одна и та же дата в разное время начинается.

Представление _времени_ (с минутами-секундами) — это не проблема вообще, а вот как народ с датами выкручивается, я бы почитал.

Date: 2013-10-13 01:19 pm (UTC)
From: [identity profile] sergiej.livejournal.com
зачем GMT+0 если таймстемп?

Date: 2013-10-13 01:20 pm (UTC)
From: [identity profile] mehanizator.livejournal.com
да, верно.

Date: 2013-10-13 10:32 pm (UTC)
From: [identity profile] lionet.livejournal.com
ISO8601: YYMMDDHHMMSS.fracZ

Date: 2013-10-13 12:58 pm (UTC)
From: [identity profile] berezovsky.livejournal.com
можно взять DateTime.ParseExact со параметром "O", где дата и время буквой T разделяются
падать по ситуации, ошибки в лог писать, наиболее серьёзные сбои - уведомлением админу, клиента успокаивать, "мы работаем над этим"

Date: 2013-10-13 01:12 pm (UTC)
From: [identity profile] berezovsky.livejournal.com
Вообще, тут желание решить задачу раз и навсегда максимально удобным, красивым и универсальным способом.
Как у Форда, который хотел создать двигатель самым мощным, надёжным и экономичным.
Но у него как-то была глобальная цель сделать автомобиль доступным рядовому гражданину.
А тут выходит, что решение должно подходить под любой будущий абстрактный проект. Не совсем понятно. :-(

Date: 2013-10-13 01:52 pm (UTC)
From: [identity profile] sbj-ss.livejournal.com
Мне нравится формат, используемый в RSS: "Fri, 20 Sep 2013 10:32:00 GMT". Несмотря на избыточность (день недели) и запись месяца строкой, отлично съедается String.TryParse().

Date: 2013-10-13 02:17 pm (UTC)
From: [identity profile] vp.livejournal.com
Съедается в какой локали?

Date: 2013-10-13 02:19 pm (UTC)
From: [identity profile] sbj-ss.livejournal.com
В нейтральной, если я правильно помню.

Date: 2013-10-13 03:27 pm (UTC)
From: [identity profile] sergiej.livejournal.com
В урле с пробелами и двоеточиями? Круто.

Date: 2013-10-13 03:31 pm (UTC)
From: [identity profile] sbj-ss.livejournal.com
Вот на что-что, а на экранирование символов в GET/POST данных есть совершенно однозначный RFC.

Date: 2013-10-14 04:30 am (UTC)
From: [identity profile] sergiej.livejournal.com
создавать проблемы, а потом их героически решать, для дат тоже есть iso но автор попросил что-то "кошерное иначе"

Date: 2013-10-14 08:43 am (UTC)
From: [identity profile] sbj-ss.livejournal.com
..и все сошлись на том, что универсального "кошерного иначе" нет :)
Следовательно, годится любой однозначно интерпретируемый формат, который можно минимальными усилиями преобразовать в машинное представление, один из которых я и предложил - пусть и произвольным образом.
Что до "героически решать" - я бы согласился, если бы пробелов, двоеточий и т.д. не могло бы быть в других параметрах запроса. На текстовые поля предустановленных форматов нет по определению.

Date: 2013-10-13 02:21 pm (UTC)
From: [identity profile] chemodax.livejournal.com
В любом случае 4xx, а не 5xx: 5xx это проблема на сервере (конфигурации или там памяти не хватает), а 4xx это что-то не так с запросом и нет смысла пробовать еще раз без изменение запроса.

Date: 2013-10-13 03:34 pm (UTC)
From: [identity profile] sbj-ss.livejournal.com
Кстати да. 5хх для "вы херню прислали" - оно повсеместно, но идеологически неправильно.
Потом "отказоустойчивый" клиент будет долбать неверными данными сервер до посинения.

Date: 2013-10-13 05:14 pm (UTC)
From: [identity profile] bydlorus.livejournal.com
time.ToString а там пусть разбираются.

Date: 2013-10-13 05:25 pm (UTC)
From: [identity profile] berezovsky.livejournal.com
так автору же разбираться :-)))))

Date: 2013-10-13 05:54 pm (UTC)
From: [identity profile] bydlorus.livejournal.com
Это завтра, а сегодня... пьём гуляем.

Date: 2013-10-13 05:26 pm (UTC)
From: [identity profile] sbj-ss.livejournal.com
Какая славная провокация.

Date: 2013-10-13 09:47 pm (UTC)
From: [identity profile] bydl0coder.livejournal.com
Чо тут думать? ISO 8601 и 400 Bad Request.

Date: 2013-10-13 09:50 pm (UTC)
From: [identity profile] no-mad.livejournal.com
Имхо, миллисекунды рулят.

Date: 2013-10-14 04:21 am (UTC)
From: [identity profile] sdfgh153.livejournal.com
Unixtime же. Самый беспроблемный способ, как мне кажется.

Date: 2013-10-14 09:11 am (UTC)
From: [identity profile] lionet.livejournal.com
ISO8601 же. Заодно и глазами посмотреть можно.

Date: 2013-10-15 09:08 am (UTC)
From: [identity profile] mak-sh.livejournal.com
Передавать дату-время в виде double - модифицированный юлианский день в дробном виде. Можно хранить в любой базе без проблем.
Знакомые баллисты так хранят чтобы не зависеть от формата времени в разных базах.

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 Aug. 14th, 2025 12:09 am
Powered by Dreamwidth Studios