Достойный парсер PHP Datetime
echo date('r',strtotime("16 Dec, 2010")); //Tue, 16 Dec 2008 20:10:00 +0530
echo date('r',strtotime("16 Dec 2010")); //Sat, 16 Jan 2010 00:00:00 +0530
Это просто неправильно ... Либо он должен выйти из строя, либо он должен правильно разобрать. Знаете ли вы какой-либо надежный парсер даты / времени на естественном языке на php? Как вы анализируете дату на естественном языке в php?
Редактировать:
var_dump(strtotime("16 Dec, abcd")); //bool(false)
«16 декабря 2010» - либо допустимый формат ввода даты GNU, либо нет. В первом случае он должен вернуть правильный ответ, а во втором - false. Вот что я имею в виду под «неправильным».
Редактировать:
Цель состоит в том, чтобы принять значительное разнообразие пользовательского ввода.
В этом нет ничего плохого, это просто отличается от того, что вы ожидаете. "респектабельные" парсеры следуют gnu.org/software/shishi/manual/html_node/…, как и strtotime
проблема заключается в том, что "тихо терпит неудачу".
Он не ошибается, он интерпретирует ваши данные иначе, чем вы ожидаете, но правильно.
Интересно, что Perl Time :: ParseDate правильно понимает первый, а 2010 интерпретирует во втором как часовой пояс. по крайней мере, у него есть такие варианты, как FUZZY и WhoLE!
Жакко, я надеюсь, что редактирование, которое я только что внесла, проясняет мой вопрос.
Ответы 5
strtotime - лучшая функция, которую вы могли найти для этого. Я сомневаюсь, что произвольное строковое представление даты когда-либо будет интерпретировано на 100% правильно, поскольку для этого потребуется как минимум информация некоторый об используемом форматировании.
Другими словами: пожалуйста, определите естественный язык (вы просто использовали две разные его версии в своем вопросе, как правильно указал интерпретатор php)
Попробуйте Ruby Date.parse. Здесь никто не хочет совершенства. Пока функция выполняет то, что обещает. Ruby Date.parse работает правильно во всех трех случаях.
Я не знаком ни с одним, хотя, может быть, кто-то может предложить уже написанное. А пока я бы рекомендовал запускать ваши данные даты через регулярное выражение или другое изменение, прежде чем передавать их через strtotime, и использовать небольшую проверку работоспособности на его выходе, чтобы увидеть, попадает ли возвращенная дата в допустимый диапазон.
Если вы знаете, в каком формате время представлено в строке, вы можете использовать strptime() вместе с соответствующей строкой формата для ее анализа. По крайней мере, он сообщит об ошибке, если не сможет интерпретировать строку в соответствии с форматом.
Эта функция существует в PHP 5.1.0 и выше.
Если вы хотите использовать произвольный пользовательский ввод, вы должны предложить пользователю четкую и очевидную обратную связь, чтобы он мог что-то сделать с ошибочно интерпретированной датой. В большинстве случаев проблем все равно не будет, и вы никогда не сможете уловить все проблемные случаи (например, американский или европейский формат).
Идея заключается в произвольном вводе данных пользователем. Я даю четкую обратную связь и автокоррекцию для европейско-американского, а теперь еще и запятую, но где эта погоня заканчивается? Думаю, я разверну свой собственный парсер, когда у меня будет немного свободного времени.
Это не неправильно, данные, которые вы предоставляете, неоднозначны - разница огромна.
Неоднозначные данные означают, что максимум, чего от них можно ожидать, - это «лучшее предположение». Вы можете не согласиться с тем, как он делает это наилучшее предположение, но это не «неправильно», это просто другое мнение о том, что наиболее вероятно. Вы не можете ожидать большего, не устранив двусмысленность.
Дальнейшие мысли, в основном связанные с комментариями к OP:
Молчаливый отказ - это не вариант - решение, когда или нет молча потерпеть неудачу, подчиняется тем же правилам и будет вызвано теми же двусмысленностями.
Какая из приведенных в примере строк неверна и должна автоматически завершиться ошибкой? А что насчет парня рядом с тобой? Он думает, что тот же неправильный? Что, если вы удалите контекст, не сравнивая их рядом?
Единственное, что здесь `` неправильно '' - это ожидание, что функция сможет расшифровать точное значение данных, которые всегда будут неоднозначными ... и это только те примеры, я еще даже не получил дат :) ( 1/2/08 - это первое февраля? Или 2 января? 1908? 2008? 8?)
Итак, я собираюсь написать функцию под названием is_this_art ...
когда вы закончите с функцией is_this_art, будет ли она с открытым исходным кодом? -)
Какой в этом смысл? Мой код всегда идеален прямо из коробки, и (близорукость === факт) определенно верно. :)
никто не говорит, что strtotime () должна быть идеальной. Я пытаюсь сказать вам, что PHP оправдает ваши надежды, а затем сокрушит вас, как баг. попробуйте это: date ('r', strtotime ("2005-02-30")). а затем скажите MIT, что эта дата неоднозначна. попробуй.
+1 @hop ... Болит непонятная частичная приверженность форматам ввода GNU Date. Я действительно не стал бы жаловаться, если бы strtotime утверждал, что выполняет нечеткое совпадение. Его нынешнее поведение непоследовательно.
@hop: Это именно то, что вы говорите, тем более, что "большие надежды". На что надеется, как не на делегирование разрешения неоднозначности? И как именно продемонстрировать ошибку в функции, которая, как вы ожидаете, способна на невозможное, какую-либо помощь в вашем положении?
«надежды» на возможность использования чего-то, что обещает придерживаться упомянутых правил формата ввода даты GNU, а затем просто не делать этого.
Язык программирования слишком прост, чтобы к нему относиться серьезно, если он даже не содержит библиотеки для волшебного анализа даты.
Существует класс Ruby под названием Chronic, который обладает необходимой гибкостью для обработки удобного пользовательского ввода: http://chronic.rubyforge.org/
Я уверен, что вы могли бы просто перенести его на PHP, заменив Ruby Time на DateTime PHP.
Боюсь, это то, с чем вы должны согласиться при использовании php