Подтвердить что ты не робот

Загадочная ошибка при анализе французских дат в OSX

У меня есть вектор символов с датами на французском языке. Я хотел бы преобразовать их в формат даты в R. Кажется, что это работает, но есть некоторые загадочные ошибки. Например, R признает "30 июня 2012 года", но не "30 juillet 2012":

> as.Date("30 juin 2012", format = "%d %B %Y")
[1] "2012-06-30"
> as.Date("28 février 2012", format = "%d %B %Y")
[1] "2012-02-28"
> as.Date("30 juillet 2012", format = "%d %B %Y")
[1] NA

Есть ли у вас какие-либо объяснения?

PS: моя локальная настройка - французский UTF8

> Sys.getlocale()
[1] "fr_FR.UTF-8/fr_FR.UTF-8/fr_FR.UTF-8/C/fr_FR.UTF-8/fr_FR.UTF-8"
4b9b3361

Ответ 1

У меня нет объяснений, но у меня есть решение. Имея аналогичные проблемы с немецкими номерами, используя "," вместо ".". для десятичных знаков и некоторых других способов написания дат. Вот что я обычно делаю с моими данными, которые находятся не в правильном формате:

a<-"30 juillet 2012"

b<-gsub(pattern="juillet", a, replacement="july")

as.Date(b, format="%d %B %Y")
[1] "2012-07-30"

Надеюсь, это поможет вам. Если "july" не работает в вашей системе, вы всегда можете заменить его на 7. Так

a<-"30 juillet 2012"
b<-gsub(pattern="juillet", a, replacement="/ 7 /")
b<-gsub(pattern="|| ", b, replacement="")
as.Date(b, format= "%d/%m/%Y")

Приветствия, Бен

Ответ 2

Как сказал GSee, это проблема локали. Установите языковой стандарт на французский язык с помощью Sys.setlocale, и пример кода будет работать нормально.

В Linux (я думаю, OS X тоже, но не протестирован):

Sys.setlocale(locale="fr_FR")

В Windows:

Sys.setlocale(locale="French_France")

Комментарий UTF-8 в GSee - это кодировка символов и не является обязательным. См. ?iconvlist для получения дополнительной информации.

Ответ 3

(Ответ на "почему?" и "как ответ" уже отправлен. Таким образом, это оставит это как то, что кажется "глубоким" объяснением, даже если это не патч на OSX. ошибка в OSX, а не R.)

Несмотря на то, что моя локаль (также на Mac) установлена ​​на "fr_FR", настройка LC_TIME остается "en_US"

> Sys.getlocale()
[1] "en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8"
> Sys.setlocale(locale="fr_FR") # Should have category="LC_ALL"
[1] "fr_FR/fr_FR/fr_FR/C/fr_FR/en_US.UTF-8"
> month.abb
 [1] "Jan" "Feb" "Mar" "Apr" "May" "Jun" "Jul" "Aug" "Sep" "Oct" "Nov" "Dec"
> month.name
 [1] "January"   "February"  "March"     "April"     "May"       "June"      "July"     
 [8] "August"    "September" "October"   "November"  "December" 

После прочтения ошибки Github для lubridate, похоже, я не сообщаю ничего нового. Думаю, у Мак есть эта ошибка. Страницы помощи говорят, что значения "month.abb" и "month.name" должны использоваться как ссылки, но их изменение также неэффективно. (Возможно, они читаются в Startup?) Сообщается о SIG-R-Mac: http://markmail.org/search/?q=+list%3Aorg.r-project.r-sig-mac+french+locale#query:%20list%3Aorg.r-project.r-sig-mac%20french%20locale+page:1+mid:oie7r5qksadmzjia+state:results

И затем, читая далее, мы видим, что ошибка находится в OSX и была там в течение некоторого времени: http://lists.freebsd.org/pipermail/freebsd-bugs/2009-December/037796.html

Я только на льве, но буду обновляться до Маверикса "сейчас скоро".

Ответ 4

Некоторые поисковые запросы на "OSX strptime juillet" вызывают этот комментарий от Peter Dalgaard http://grokbase.com/t/r/r-sig-mac/12696r26eh/as-date-does-not-work-with-format-b:

Похоже, что это

http://lists.freebsd.org/pipermail/freebsd-bugs/2009-December/037796.html

который был зафиксирован в мае 2010 года, но, по-видимому, не обновления OSX пока отсутствуют. (Все еще там, в местном построении на Льве, так что не только CRAN. Вставьте соответствующую информацию о Open Source и коммерческие продавцы здесь...)

Резюме ошибки: strptime с% B проходит через месяцы и проверки для полного имени, затем аббревиатуры. Проблема в том, что "jui" из "juillet" совпадения abbr. для "juin"! но "llet" не соответствует% Y, и мы получаем NA.

Итак, это ошибка BSD, которая сохраняется в OSX.

Похоже, вам придется использовать что-то вроде решения @Ben K, чтобы обойти это. (К сожалению.)