Тупой и еще тупее

[metaclass]

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

Comments

[sbj-ss.livejournal.com]

Мне нравится формат, используемый в RSS: "Fri, 20 Sep 2013 10:32:00 GMT". Несмотря на избыточность (день недели) и запись месяца строкой, отлично съедается String.TryParse().

[vp.livejournal.com]

Съедается в какой локали?

[sbj-ss.livejournal.com]

В нейтральной, если я правильно помню.

[sergiej.livejournal.com]

В урле с пробелами и двоеточиями? Круто.

[sbj-ss.livejournal.com]

Вот на что-что, а на экранирование символов в GET/POST данных есть совершенно однозначный RFC.

[sergiej.livejournal.com]

создавать проблемы, а потом их героически решать, для дат тоже есть iso но автор попросил что-то "кошерное иначе"

[sbj-ss.livejournal.com]

..и все сошлись на том, что универсального "кошерного иначе" нет :)
Следовательно, годится любой однозначно интерпретируемый формат, который можно минимальными усилиями преобразовать в машинное представление, один из которых я и предложил - пусть и произвольным образом.
Что до "героически решать" - я бы согласился, если бы пробелов, двоеточий и т.д. не могло бы быть в других параметрах запроса. На текстовые поля предустановленных форматов нет по определению.