Тупой и еще тупее
Oct. 13th, 2013 03:04 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassСкажите мне пожалуйста, существует ли общепринятый метод передачи дат или даты-времени в параметрах URL для сервиса, например?
Сколько не пишу подобное - практически всегда все сводится к "прибиваем гвоздями ISO8601, парсим строку руками и под каждую задачу заново решаем, что делать с невалидными строками - то ли валится с 4хх, то ли валится с 5хх, то ли игнорировать ошибки, использовать или нет TryParse (если он вообще есть, обычно нету - "у нас всегда все работает, а невалидных дат не бывает") и как возвращать сообщения об ошибках клиенту так, чтобы он мог хоть что-то вменяемое сделать.
Сколько не пишу подобное - практически всегда все сводится к "прибиваем гвоздями ISO8601, парсим строку руками и под каждую задачу заново решаем, что делать с невалидными строками - то ли валится с 4хх, то ли валится с 5хх, то ли игнорировать ошибки, использовать или нет TryParse (если он вообще есть, обычно нету - "у нас всегда все работает, а невалидных дат не бывает") и как возвращать сообщения об ошибках клиенту так, чтобы он мог хоть что-то вменяемое сделать.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-10-14 04:30 am (UTC)no subject
Date: 2013-10-14 08:43 am (UTC)Следовательно, годится любой однозначно интерпретируемый формат, который можно минимальными усилиями преобразовать в машинное представление, один из которых я и предложил - пусть и произвольным образом.
Что до "героически решать" - я бы согласился, если бы пробелов, двоеточий и т.д. не могло бы быть в других параметрах запроса. На текстовые поля предустановленных форматов нет по определению.