Dates entered in the "short date" format in Excel were imported differently into OpenRefine. For example, 8/30/2019 in Excel became Fri Aug 30 00:00:00 EDT 2019 in OpenRefine. I would like to get them back to a short date (mm/dd/yyyy) or even a string (mmddyyyy) format, with no day of week, time, or time zone data retained. I've been trying to transform them but can't figure out the grel code.
The toString() function takes an optional format string that you can use for this. You can use value.toString('M/d/y') (or toString(value,'M/d/y'))to get a string in the format of your first example. Note, however, that once you convert it to a string you'll lose the ability to use any of the date related functions like calculating how far apart two dates are.
Related
I know that ACCESS's time format depends on your Windows time settings. I use ISO-8601 format (YYYYMMDD) so that I can get away with SQL WHERE statements like this one:
WHERE dates > #2020/02/15#
AND dates < #2021/01/30#
If I run the code from above in another computer, whose Windows time settings are for example DDMMYYYY, will the SQL statement no longer work? I could simply do something like this to solve that problem (will it though?):
WHERE dates BETWEEN Format(date1, "\#YYYY\/MM\/DD\#") AND Format(date2, "#YYYY\/MM\/DD\#")
EDIT: Time format has beign changed as pointed out by #Gustav. The question remains; will the first WHERE Statement no longer work on different Windows time settings? Will the second correct the problem?
In Access SQL, use octothorpes:
WHERE dates > #2020/02/15#
AND dates < #2021/01/30#
WHERE dates BETWEEN Format(date1, "\#YYYY\/MM\/DD\#") AND Format(date2, "#YYYY\/MM\/DD\#")
Nope, Windows time settings will mess with a lot of things, but not with ordering or comparisons with dates.
As long as the field is defined as a date (so with octothorpes, like Gustav said), the 2nd of February 2021 will be less the 11th of February 2021, even though that wouldn't be the case if you cast them to a string first.
Always try to keep columns as they are when filtering, so if dates is actually a date column (and not a formatted string), just use WHERE dates BETWEEN #2020/02/15# AND #2021/01/30#, no formats, no funky stuff. And note that especially when trying to keep your application working in all locales, it's important to avoid casting dates to strings, which can happen if you compare a date with a formatted string.
I'm working with SQL in MS Access. One of the columns that I import from Excel has date and time in an odd format as below:
Jan 12 2021 07:55:14 AM PST
MS Access doesn't recognize this as date and time so doesn't convert it as such. I'm trying to automate some steps so don't want the user to manually delimit this column in excel and convert to DD-MM-YYYY format.
I just need to extract the dates which are almost always 11 characters in length. However, as I'm new to this, I am unable to parse it as such and the existing posts don't help much (or maybe I can't understand).
Assuming value always ends with " PST" (or any 3 characters following a space), consider:
CDate(Left([fieldname], InStrRev([fieldname], " ")-1))
That returns a valid date/time. Formatting can be applied to extract only m/d/y parts. Be aware, Format function returns a string, not a true date.
Format(Left([fieldname], InStrRev([fieldname], " ")-1), "mm/dd/yyyy")
I need to retrieve a tuple from the database that have a DateTime as a primary key, the problem i'm having is that it's only working with Datetime's that have the time before midday, otherside it fails to retrieve anything, here is the code:
string fecha = "22-11-2016 15:56:50";
DateTime myDate = DateTime.ParseExact(fecha, "dd-MM-yyyy HH:mm:ss", System.Globalization.CultureInfo.InvariantCulture);
modelo.solicitud = BD.Solicitud.Find(myDate);
in resume I get a null in modelo.solicitud
if the string fecha is like "01-01-2017 09:00:00" (before midday) it success to retrieve from database, but if it's like "01-01-2017 16:00:30" will fail to retrieve a thing..
Any help of recomendation will be appreciated..
Regardless of the DBMS you are using, fields (columns) that are defined as DATETIME are stored as a binary value. What you see is a generated string representation of the binary value according to either the defaults defined for the DB or a specific format you define for presentation.
You can try setting the default datetime format to something like 'yyyy-mm-dd hh24:mm:ss' (hh24 is Oracle's way to say that you want the hours part to be in the 0-23 range; you will need to check how this is done in your case).
This format also removes ambiguities related to the American/European way of writing dates (i.e. mm/dd/yyyy in the US vs. mm/dd/yyyy in Europe, such that 3/4/16 would mean March the 4th 2016 in the US but April the 3rd 2016 in Europe).
Last, the Spanish word resume has a different meaning than in English (you would normally say summary).
Hope this is clear for you now.
I have a column which saves date in a varchar format. I can't change it because it is a part of the existing system. I need to convert this to datetime because I need to apply the datediff function.
The problem is that the dates are in several different formats.
Example:
14/09/2013 dd/mm/yy
20-06-2014 dd-mm-yy
1/29/2013 mm/dd/yy
2013-05-30-15.10.04.812055
8/3/2012 4:22:16 PM dd/mm/yy or mm/dd/yy can't make out the difference
I thought of switching dd and mm but that will be confusing to identify especially with the 1st 3rd and last case. When I convert as is, it gives me an out of range error. How do I fix this?
I am currently using SQL Server 2008
In Excel 2010 VBA, I'm testing to make sure my code handles invalid user input correctly. I'm using CDate to validate date inputs. I've found that with the invalid date input "0/5/14", CDate returns the date 5/14/2000.
Is that a CDate bug, or am I missing something? In an Excel worksheet cell, "0/5/14" does not evaluate to a date.
Similarly, Year("0/5/14") in Excel VBA returns 2000, while =Year("0/5/14") in an Excel worksheet cell returns an error.
Windows regional settings are English USA, so month/day/year is standard.
The CDate function (and other string-to-date functions such as DateValue) examines a string representation of a date and attempts to match it to any known date format, considering it to be a valid date unless it cannot be made to match any of the known formats. Since it can be the case that years can be expressed as 1 or more digits, the input string "0/5/14" can be considered to be in year/month/day format, so it returns "14th of May, 2000" in your local date format.
The difference between CDate and DateValue is that CDate can accept a number, while DateValue cannot. Both use the PC's Short Date format first - not that that would matter for someone using en-US settings. Both functions fall back to other date formats if the supplied string doesn't fit on the first attempt.
It is up to you how you handle such situations. It may well be that in your situation, a date in year 2000 would be out-of-range, so you could reject it on that basis. If you want to insist on "mm/dd/yyyy" format, you could write your own parser code.
I believe #Borja Güiles Quintana had the correct answer with basically it's reading it as YY/MM/DD. CDate does not exist as a worksheet function so it does not surprise me that the sheet (as opposed to VBA) interpretation differs (would not be the first time, eg TRIM).
Any year (and which part represents year may be system dependent) is interpreted according to rules (that may be version dependent) but for Excel 2013 and two-digit values these stop at 29 for this century - ie 30 is interpreted as 19 30. More details of that here.