![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Тупой и еще тупее
Скажите мне пожалуйста, существует ли общепринятый метод передачи дат или даты-времени в параметрах URL для сервиса, например?
Сколько не пишу подобное - практически всегда все сводится к "прибиваем гвоздями ISO8601, парсим строку руками и под каждую задачу заново решаем, что делать с невалидными строками - то ли валится с 4хх, то ли валится с 5хх, то ли игнорировать ошибки, использовать или нет TryParse (если он вообще есть, обычно нету - "у нас всегда все работает, а невалидных дат не бывает") и как возвращать сообщения об ошибках клиенту так, чтобы он мог хоть что-то вменяемое сделать.
Сколько не пишу подобное - практически всегда все сводится к "прибиваем гвоздями ISO8601, парсим строку руками и под каждую задачу заново решаем, что делать с невалидными строками - то ли валится с 4хх, то ли валится с 5хх, то ли игнорировать ошибки, использовать или нет TryParse (если он вообще есть, обычно нету - "у нас всегда все работает, а невалидных дат не бывает") и как возвращать сообщения об ошибках клиенту так, чтобы он мог хоть что-то вменяемое сделать.
no subject
И не дай бог контрол на странице использует локаль пользователя, а парсится с локалью сервера.
Сайт нормально работает только до 12 числа каждого месяца :)
no subject
no subject
Понятно что для сайта лечится просто -показываем в локали пользователя, но везде работаем и храним в локали сервера.
Но для рестфул сервиса или сайта с внешним апи пляски обеспечены.
no subject
no subject
no subject
no subject
no subject
no subject
А ошибки парсинга -- ну, как и в любых других случаях обрабатывать, чем дата/время тут особенны?
no subject
no subject
no subject
Точек отсчёта придумано стопицот, но на моей памяти ни одна не учитывает интересы историков. Когда несколько лет назад у нас на конторе зашла речь об обучающей системе именно по истории, то вообще предлагалась безумная идея собственного формата с распихиванием по битам (чтобы влезть в 4 байта на x86), который в SQL Server хранился просто в int - чтобы обеспечить поиск и сортировку. Это не от хорошей жизни, а от отсутствия альтернатив.
Впрочем, "даты до 1970" касаются не только историков. Даты рождения, например.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
И как представлять величины типа "учетная дата" (у нее времени нет, соотвественно, представление с секундами для нее противоречиво")
no subject
no subject
no subject
no subject
Представление _времени_ (с минутами-секундами) — это не проблема вообще, а вот как народ с датами выкручивается, я бы почитал.
no subject
no subject
no subject
no subject
падать по ситуации, ошибки в лог писать, наиболее серьёзные сбои - уведомлением админу, клиента успокаивать, "мы работаем над этим"
no subject
Как у Форда, который хотел создать двигатель самым мощным, надёжным и экономичным.
Но у него как-то была глобальная цель сделать автомобиль доступным рядовому гражданину.
А тут выходит, что решение должно подходить под любой будущий абстрактный проект. Не совсем понятно. :-(
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Следовательно, годится любой однозначно интерпретируемый формат, который можно минимальными усилиями преобразовать в машинное представление, один из которых я и предложил - пусть и произвольным образом.
Что до "героически решать" - я бы согласился, если бы пробелов, двоеточий и т.д. не могло бы быть в других параметрах запроса. На текстовые поля предустановленных форматов нет по определению.
no subject
no subject
Потом "отказоустойчивый" клиент будет долбать неверными данными сервер до посинения.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Знакомые баллисты так хранят чтобы не зависеть от формата времени в разных базах.