Даты от Excel до R, зависимости от платформы

Я импортирую файлы xls, используя gdata. Я конвертирую столбцы даты с помощью as.Date для преобразования даты

В соответствии с руководством для as.Date, начало даты зависит от платформы, и поэтому я определяю, какое происхождение использовать соответственно

.origin <- ifelse(Sys.info()[['sysname']] == "Windows", "1899-12-30", "1904-01-01")
as.Date(myData$Date, origin=.origin)

Однако мне интересно, следует ли мне рассматривать платформу, где читается файл, или платформу, на которой она была написана?

Для чего это стоит, я в настоящее время тестирую код в ящике Linux без excel, и правильные Даты создаются с помощью origin="1904-01-01"

Цитирование `? as.Date '

  ## date given as number of days since 1900-01-01 (a date in 1989)
  as.Date(32768, origin = "1900-01-01")
  ## Excel is said to use 1900-01-01 as day 1 (Windows default) or
  ## 1904-01-01 as day 0 (Mac default), but this is complicated by Excel
  ## treating 1900 as a leap year.
  ## So for dates (post-1901) from Windows Excel
  as.Date(35981, origin = "1899-12-30") # 1998-07-05
  ## and Mac Excel
  as.Date(34519, origin = "1904-01-01") # 1998-07-05
  ## (these values come from http://support.microsoft.com/kb/214330)

Ответы

Ответ 1

Вы можете попробовать (чрезвычайно) новый пакет exell: https://github.com/hadley/exell. Он загружает даты excel в POSIXct, правильно выбирая источник, основываясь на том, был ли файл написан Windows или Mac Excel.

Ответ 2

Да, вы должны подумать, где был написан файл. Excel-Windows может отличать даты, написанные Mac, от дат, записанных в Win, но вы получаете доказательства того, что это файлы с расширением .xls от Mac.

Самый безопасный метод - работать в версии Excel, на которой были введены данные, и использовать меню формата, чтобы открыть диалоговое окно, из которого вы выбираете дату-Date и пользовательский формат yyyy-mm-dd, Затем сохраните как файл csv, и вы сможете импортировать в R с вектором colClasses "Date" в правильной позиции столбца. Но это звучит так, как будто это вариант недоступен.

Я полагаю, что это не относится к вам в linux-блоке, так что это всего лишь Mac-whine: gdata-package дает предупреждения об устаревании, а затем не удается установить файлы поддержки XLSX на R 3.0.0 с обычным Perl 5.8 в '/opt/local/bin/perl'. Это несмотря на то, что gdata:: findPerl может найти его успешно.

В этот момент я думаю, что вопрос должен быть перенаправлен на вопрос, можно ли уговорить функции gdata проверять свойства файлов. После глядя на кодовую базу для чтения xls, я скорее сомневаюсь в этом, так как не вижу упоминания об осмотре для разных версий xls.

В конце пустого файла xls, созданного с помощью Mac-версии Excel, глядя в текстовый редактор, я вижу:

Worksheets˛ˇˇˇˇˇ ¿F$Microsoft Excel 97 - 2004 Worksheet˛ˇˇˇ8FIBExcel.Sheet.8˛ˇ
‡ÖüÚ˘Oh´ë+'≥Ÿ0îHPhħ
∞ºƒ'David WinsemiusDavid WinsemiusMicrosoft Macintosh [email protected]ê˚á!Ë+Œ@ê'å-Ë+ŒG»˛ˇˇˇPICT¿Kġ

Другое отличие заключалось в том, что в версии Windows, проверенной таким же образом, был "Рабочий лист Excel 2003" в качестве типа рабочего листа, тогда как для версии Mac был "Excel 97 - 2004". Поэтому, возможно, вы можете принудить R к обходу всех ошибок, которые возникают при чтении или grepping во время сканирования для "Macintosh". Может быть, Linux-R более устойчив к подобным вещам?

Error: invalid multibyte string at '<ff>'

Я также получил кучу предупреждений от grep, которые предположили, что я не могу "видеть" в некоторых строках:

Warning message:
In grep("Macintosh", lin) : input string 1 is invalid in this locale

Возможно, вы сможете перенести еще более надежный код из кода Perl в xls2csv.pl, который является частью пакета gdata.