I am importing an excel file that has a date field with the following format: dd/mm/YYYY
It imports the data OK, however it does something strange with the dates. If the day is higher than 12, then it takes the current date.
I found this on the log:
WARNING: unrecognized date format ``, assigning current date
For example: the date 08/04/2020 is imported ok because 08 <= 12, however the date 23/02/2020 is not imported because 23 is not <= 12, and then it takes the current date.
Any ideas about what is happening?
This issue can get confusing with Excel, since typically, if the system is set for U.S. locales, Excel converts standard European date format in day-month-year to some version of month/day/year. In other words, tThe forward slash usually indicates American format, which is month first, as in April 9, 2022 or 04/09/22. You can force day/month/year, and apparently that was done for your file or system, but that's not an expected or standard format.
Without examining All Import code in detail, I'd say the behavior you describe implies it is presuming the standard usage. I'd therefore recommend that you try converting your date column before attempting imports, but how to do that efficiently would probably be more an Excel question than a WordPress question, unless you are able in your version of All Import to perform a custom conversion on the field.
A trick that sometimes works on this type of problem is copy-pasting Excel data into a Google Sheet, then downloading as CSV, without ever opening the file in your system before re-uploading. Google Sheets is pretty good about such conversions in general, but no guarantees: Your source file might defeat it in this case.
I had the same issue. Change the dates in your csv file to mm/dd/yyyy and when it imports it will automatically convert to dd/mm/yyyy if that is what your WP website is set up to use.
Only numbers lower than 12 will work the way you are importing because there are only 12 months in a year and it is reading you dd as mm.
Related
I am working an uploaded document originally from google docs downloaded to an xlsx file. This data has been hand entered & formatted to be DD-MM-YY, however this data has uploaded inconsistently (see example below). I've tried a few different things (kicking myself for not saving the code) and it left me with just removing the incorrectly formatted dates.
Any suggestions for fixing this in excel or (preferably) in R? This is longitudinal data so it would be frustrating to have to go back into every excel sheet to update. Thanks!
data <- read_excel("DescriptiveStats.xlsx")
ex:
22/04/13
43168.0
43168.0
is a correct date value
22/04/13
is not a valid date. it is a text string. to convert it into date you will need to change it into 04/13/2022
there are a few options. one is to change the locale so the 22/04/13 would be valid. see more over here: locale differences in google sheets (documentation missing pages)
2nd option is to use regex to convert it. see examples:
https://stackoverflow.com/a/72410817/5632629
https://stackoverflow.com/a/73722854/5632629
however, it is very likely that 43168 is also not the correct date. if your date before import was 01/02/2022 then after import it could be: 44563 which is actually 02/01/2022 so be careful. you can check it with:
=TO_DATE(43168)
and date can be checked with:
=ISDATE("22/04/13")
I have a file that I am reading in. Everything is fine, except for one detail. In the file, dates are stored in the format "mm/dd/yyyy". When I try to read this in with fread, I'm using
fread(..., select = c(var = "Date"))
It appears fread assumes it's in the ISO format, so January 9, 2019 stored as 1/9/2019 is read in as the date"0001-09-20", September 20, year 1. Is there any way to specify a format to tell fread how to read this? It could be in select or colClasses, though select is my preference as I've already selected around 80 columns and specified their data types.
I know I could read it in as character and change it afterward. I'm trying to do as much as possible while reading in the data. If I have to change it after the fact, I will do that.
You have two options.
Read as character and convert in extra step.
Fill feature request in data.table github repo providing your minimal example file and wait for it to be implemented.
Personally I would go with the first one. Good thing is that you can do both.
How, i can keep date format same of excel at the time of download in different-2 time zone?
My downloaded file contains date column format is MM-dd-YYYY.
The issue is that, while i am downloading the excel file in US region it is not converting the dates into different formats, while i am downloading the same file in UK region, it is converting the dates into dd-MM-YYYY.
Date 12-01-2015 is converting to 01-12-2015.
I want to keep date format of excel file MM-dd-YYYY in all the regions.
I am generating the file using ASP.Net C#.
Thanks in advance.
This is because Excel is selecting the different date format based on the program's locale setting. I would imagine your options are:
a: Change the cell format to what you need in each location, e.g. in VBA the code would be something like Selection.NumberFormat = "m/d/yyyy;#"
b: Store your date data in text format. So literally a text string in mm-dd-yyyy format. You could still easily parse it later.
I am rendering a table report via googleVis version 0.5.10. My data contains date columns. When I render table report I get date columns formatted with the full month names in them. By default they are using default language, which is Russian for me.
How do I set language in googleVis to English, so it could be passed to google?
Thank you.
Maybe a little late for an answer, but I've only recently seen your post while googling for the same issue with an app I developed, where dates where expressed in italian (eg. 24 June 2017 was shown as 24 Giu 2017).
In my case I was rendering a gvisLineChart and setting the gvis.language parameter (options=list(gvis.language="en", ) didn't work.
I was able to make it work by specifying the date format in the statement used to build the dataframe I need.
chart3 <- aggregate(geoData[,c("slug")], by=list(format(as.Date(geoData$timestamp),"%d %b %Y")), FUN=length)
Since you haven't posted any code I'm not able to suggest more solutions to your problem, but I guess you should try to set format as well.
I'm importing xls files using gdata. I am converting date columns using as.Date to convert the date
As per the manual for as.Date, the date origin is platform dependent, and so I am determining which origin to use accordingly
.origin <- ifelse(Sys.info()[['sysname']] == "Windows", "1899-12-30", "1904-01-01")
as.Date(myData$Date, origin=.origin)
However, I'm wondering if I should be considering the platform where the file is being read or the platform where it was written?
For what it's worth, I am currently testing the code on a linux box with no excel, and the correct Dates are produced by using origin="1904-01-01"
Quoting `?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)
You could try out the (extremely) new exell package: https://github.com/hadley/exell. It loads excel dates into POSIXct, correctly choosing the origin based on whether the file was written by Windows or Mac Excel.
Yes, you should be considering where the file was written. Excel-Windows appears capable of distinguishing Mac-written dates from Win-written dates, but you are getting evidence that these are Mac-originated .xls files.
The safest method would be to work within the version of Excel on which the data was entered and to use the format menu to bring up a dialog box from which you choose as-Date and a custom format of yyyy-mm-dd. Then save as a csv file and you will be able to import into R with the colClasses vector "Date" in the proper column position. But that sounds as though it is an option not available.
I suppose it doesn't apply to you on a linux box so this is just a Mac-whine: The gdata-package gives deprecation warnings and then fails to install the XLSX support files on R 3.0.0 with the ordinary Perl 5.8 installation in '/opt/local/bin/perl'. This despite 'gdata::findPerl` being able to find it successfully.
At this point I think the question should be redirected to inquiring whether you could coax gdata functions into inspecting the properties of the files. After looking at the codebase for xls reading, I rather doubt it, since do not see any mention of inspecting for different xls versions.
Near the end of a blank xls file created with a Mac version of Excel, looking with a text editor I see:
Worksheets˛ˇˇˇˇˇ ¿F$Microsoft Excel 97 - 2004 Worksheet˛ˇˇˇ8FIBExcel.Sheet.8˛ˇ
‡ÖüÚ˘Oh´ë+'≥Ÿ0îHPhħ
∞ºƒ'David WinsemiusDavid WinsemiusMicrosoft Macintosh Excel#ê˚á!Ë+Œ#ê'å-Ë+ŒG»˛ˇˇˇPICT¿Kġ
The other difference was that the Windows version inspected the same way was had "Excel 2003 Worksheet" as teh type of worksheet, whereas it was "Excel 97 - 2004" for the Mac version.
So maybe you can coerce R into bypassing all the errors that get triggered when reading or grepping during scanning for "Macintosh". Maybe Linux-R is more resistant to that sort of thing?
Error: invalid multibyte string at '<ff>'
I also got a bunch of warnings from grep that suggested I might not be able to "see" into some of the strings:
Warning message:
In grep("Macintosh", lin) : input string 1 is invalid in this locale
You might be able to highjack some more robust code from the Perl code in xls2csv.pl which is part of the gdata package.