trabajar - Fechas de Excel a R, dependencia de la plataforma
subir archivo de excel ar (2)
Sí, deberías considerar dónde se escribió el archivo. Excel-Windows parece capaz de distinguir las fechas escritas de Mac de las fechas escritas por Win, pero está obteniendo evidencia de que estos son archivos .xls originados en Mac.
El método más seguro sería trabajar dentro de la versión de Excel en la que se ingresaron los datos y utilizar el menú de formato para que aparezca un cuadro de diálogo desde el que elija como-Fecha y un formato personalizado de aaaa-mm-dd. Luego guarde como un archivo csv y podrá importar a R con el vector colClasses "Fecha" en la posición correcta de la columna. Pero eso suena como si fuera una opción no disponible.
Supongo que no se aplica en un linux box así que esto es solo un Mac-whine: el paquete gdata da advertencias de desaprobación y luego no instala los archivos de soporte XLSX en R 3.0.0 con la instalación normal de Perl 5.8 en ''/ opt / local / bin / perl''. Esto a pesar de que ''gdata :: findPerl` puede encontrarlo con éxito.
En este momento, creo que la pregunta debe redirigirse para preguntar si puede convencer a las funciones gdata para que inspecten las propiedades de los archivos. Después de mirar la base de código para la lectura de xls, lo dudo, ya que no veo ninguna mención de inspección para diferentes versiones de xls.
Cerca del final de un archivo xls en blanco creado con una versión Mac de Excel, mirando con un editor de texto veo:
Worksheets˛ˇˇˇˇˇ ¿F$Microsoft Excel 97 - 2004 Worksheet˛ˇˇˇ8FIBExcel.Sheet.8˛ˇ
‡ÖüÚ˘Oh´ë+''≥Ÿ0îHPhħ
∞ºƒ''David WinsemiusDavid WinsemiusMicrosoft Macintosh Excel@ê˚á!Ë+Œ@ê''å-Ë+ŒG»˛ˇˇˇPICT¿Kġ
La otra diferencia era que la versión de Windows inspeccionada de la misma manera tenía "Hoja de cálculo de Excel 2003" que el tipo de hoja de trabajo, mientras que era "Excel 97 - 2004" para la versión de Mac. Por lo tanto, tal vez pueda forzar a R a pasar por alto todos los errores que se desencadenan al leer o almacenar durante el escaneo de "Macintosh". ¿Tal vez Linux-R es más resistente a ese tipo de cosas?
Error: invalid multibyte string at ''<ff>''
También recibí un montón de advertencias de grep que sugerían que podría no ser capaz de "ver" algunas de las cadenas:
Warning message:
In grep("Macintosh", lin) : input string 1 is invalid in this locale
Es posible que pueda obtener un código más robusto del código Perl en xls2csv.pl, que es parte del paquete gdata.
Estoy importando archivos xls usando gdata . Estoy convirtiendo columnas de fecha usando as.Date para convertir la fecha
Según el manual para as.Date , el origen de la fecha depende de la plataforma, por lo que estoy determinando qué origen utilizar en consecuencia
.origin <- ifelse(Sys.info()[[''sysname'']] == "Windows", "1899-12-30", "1904-01-01")
as.Date(myData$Date, origin=.origin)
Sin embargo, me pregunto si debería considerar la plataforma donde se está leyendo el archivo o la plataforma donde se escribió .
Por lo que vale, actualmente estoy probando el código en un cuadro de Linux sin Excel, y las fechas correctas se producen utilizando origin="1904-01-01"
Citando `? 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)
Puede probar el (extremadamente) nuevo paquete Exell: https://github.com/hadley/exell . Carga las fechas de Excel en POSIXct, eligiendo correctamente el origen según si el archivo fue escrito por Windows o Mac Excel.