I have various peoples' DOBs. I want to convert them to a format that will serve as their predicted-but-incomplete NY Driver's License expiration date (which is always the person's DOB in some later year). Because (for now) all of the license expiration dates will be sometime before 2030, I would like to essentially chop off the year portion of the DOBs and replace them with "202_" (or if that's not feasible then just "202").
I know how to get Excel to display the DOB without the year, but that isn't helping me so far. My hope had been to use CONCAT to start with that truncated display and then just add "202_" but the date format of the truncated DOB is tripping me up. If I could get Excel to treat the truncated/display DOB as text without Excel converting it to its number version of the whole DOB then that would seem to solve the problem... Or maybe there's another approach I haven't thought of yet?
You can use following formula:
=TEXT(A1,"dd.MM.") & "202_"
Change date format "dd.MM" as you need
Related
If I display a date in cell A1 using the cell format [$-8040D] d to show the day of the jewish month, I get a number (from 1 to 30) instead of -the way it is normally displayed- a hebrew letter.
So I want to use
=CHOOSE(A1,"א","ב","ג","ד","ה","ו","ז","ח","ט","י","יא","יב","יג","יד","טו","טז","יז","יח","יט","כ","כא","כב","כג","כד","כה","כו","כז","כח","כט","ל")
But even though I see a number 1-30 displayed in A1, what's really there is a date serial code (something like "44181").
I have tried N(), and VALUE().
What's the correct way to do it?
Thanks!
Excels stores dates numbers as per the Gregorian calendar with 1 = 1 Jan 1900 (and 1900 erroneously being deemed a leap year for competitive reasons).
So first you need to convert the date to the Jewish date (I'm assuming the Jewish Lunar calendar); extract the day of the month(with the TEXT function), and then convert that value to its Hebrew letter equivalent.
eg:
=CHOOSE(TEXT(A1,"[$-he-IL,8]dd"),"א","ב","ג","ד","ה","ו","ז","ח","ט","י","יא","יב","יג","יד","טו","טז","יז","יח","יט","כ","כא","כב","כג","כד","כה","כו","כז","כח","כט","ל")
or:
=CHOOSE(TEXT(A1,"[$-8040D]d"),"א","ב","ג","ד","ה","ו","ז","ח","ט","י","יא","יב","יג","יד","טו","טז","יז","יח","יט","כ","כא","כב","כג","כד","כה","כו","כז","כח","כט","ל")
So for today which is
the formula would return
The "correct" way to do it is to realize there is no problem here, no problem at all.
Yes, Excel uses a serial number dating system. However, it completely knows how to interpret it too. So you will have a serial number as the "real" content of A1, but can extract from it the day of the month value. You can do this with:
=TEXT(A1,"d")
This gets you a TEXT "6" if it is December 6. Often that fact (that it returns TEXT) can cause trouble. But only when Excel could expect you could mean either and has to guess which. In the case of the above formula it would be reasonable for it to assume you wanted it looked at as text since the function is... TEXT()...
But in this case, using it in the CHOOSE() function it can ONLY be useful if Excel treats it as a value rather than text. So it does. No need to add anything to force Excel to do so.
So you can just replace the A1 portion of your formula with the above TEXT() function. Then Excel will use it properly and select the correct day of the month from the list.
And that's all you need.
I've been struggling with Excel (2016) date formats. I know how to change display formats for dates and cells but the problem I have is the input format for dates. If I input a date as "DD.MM" or "DD.MM.YYYY" it does recognize it as a date but if I input the date as "DD.MM." (with the second dot after the month), Excel does not recognize it as a date anymore. The column in question is formatted as short date.
Is there anything that can be done or is this by-design? If so, it seems really strange as at least in my country it's the official way to write the date containing that second dot after the month number when there is no year included in the date.
I've been searching and Googling for solution but couldn't find anything on this really. I appreciate all comments and help regarding this question!
SUMMARY/TL;DR:
Excel version is 2016, country is Finland and language is finnish
Excel accepts/recognizes these as dates: 12.5 or 30.8
Excel does NOT accept/recognize these as dates: 12.5. or 30.8.
The column in question is formatted as short date
The dot after the month seems to be screwing things up
Why is this happening? Can anything be done?
Kind regards,
Tenttu
Yes, it is/was by design. (Funny enough, my Excel won't allow dots, only dashes (-), so I couldn't even test if "15.8" works)
So, there's a slight chance that the language of Excel (the defaults of time (24 hours or AM/PM), dates (MM/DD or DD/MM), decimals (comma or dot) etc.) wouldn't allow the dot at after the month. Here's an example of a user that has that dot, and wants to get rid of it. So, your system language is a good candidate for why this wouldn't work for you.
However, I realize that the example linked above don't feature a date with a dot at the end. Which could suggest it is rather by design. For example, if I add a dot to a valid date or time, it will result in some #VALUE!-error. And that's because of how Excel is programmed to convert text to a date - and remember, dates are actually just really large numbers. So, adding a dot at the end makes that conversion "impossible". We might think it's as easy as to remove a dot, but in programming, we need to program that explicitly to do that, and I'm leaning towards there is no such operation done during text to date conversion (certainly not on my system, as I get #VALUE!).
One work-around is to strip the ending dot from the date to make it a valid date. So, you can import sheets with dates with dots at the end, then strip them away, and you'll be good to go!
I am reading data from an excel sheet and the 5th column is a date field. I have the following logic to ensure that the input date is converted to YYYY-MM-DD format -
var valid_from = new Date(data[counter][5]);
valid_from_new = var formatedDate = moment(valid_from).format("YYYY-MM-DD");
reqBody.valid_from = valid_from_new.toString();
I have the date 2017-10-10 to begin with and I am able to read it fine via my node app. It works for me as long as I do not edit this field in my Microsoft Excel 2010. If I edit it or simply find/replace the values, I get unix default date (1970-01-01) in reqBody.valid_from.
To find out what happens after the replacement, I checked that if I replace 2017-10-10 with 2017-10-20 and then "clear formats" (excel utility), I get 43028 displaying in the sheet, whereas for the date 2017-10-10 it remains the same, i.e. 2017-10-10. I don't understand why excel behaves like this.
Can this be handled uniformly by my application? I just want to make the "YYYY-MM-DD" format work across any excel versions. It would be fine if I could do one format change or clear format once before feeding the file and it would work.
I don't understand why excel behaves like this.
Excel behaves like that as it stores 2017-10-10 as a serial date. Meaning it is an integer representing the number of days that have past since January 1st 1900 for the Windows system. (potentially 1905 or something similar for mac). In your specific case its apparently 43028. It displays a converted date in a format people read as 2017-10-10 in your case. You will note this as your formatting for the cell is either a date of some sort or a custom user format. If you entered the date as text by leading it with a ' you would note the format does not change when you change the cell formatting. The date is actually just text and not a formatted date. Numbers that are enter in a format that looks like a date to excel, excel will usually attempt to automatically convert them to a serial date value for you. It has a built in list of formats it looks for and I believe also looks at your system settings format too.
As a side note, the decimal portion of the number represents time. Fraction of a day. 0 is 00:00:00 and .5 is 12:00:00.
Can this be handled uniformly by my application?
I am sure the answer to this is "yes" but is beyond my expertise. I highly suspect it is because your code is handling it as text initially. Things go wrong when it receives the integer from excel that represents the date in excel.
It seems that every week or so someone posts a question about dates being converted (corrupted?) to American format. Like many others, I have attempted to help but the problem is elusive. I now wonder if I have discovered the cause.
I am working on an application in which I need to extract data from an Excel worksheet and output it as strings formatted to match the value the Excel user can see. So if the value is “1” formatted to display as “1.00” then I want the string to be “1.00”.
I achieve this effect by testing the cell value to be a number, date or time. If it is, I retrieve the number format and use it to format the cell value so:
With .Cells(Row, Column)
Output string = Format(.Value, .NumberFormat)
End With
In most cases this gives me exactly the output I require. However, sometimes I get American dates and times when the source is formatted as a UK date or time.
After much experimentation with Excel 2003 and Excel 2007, I have discovered the cause. (I do not have access to Excel 2010 but from questions I deduce it has the same problem.) This question is in part intended to reveal this problem to the world because I can discover nothing on the internet to indicate that anyone else has noticed it. (No doubt someone will reply that they googled “xyz” and got the answer immediately.) However, the main purpose of this question is to seek suggestions for obtaining the result I need in all situations.
Typically I enter dates as, for example, “23mar12”. Excel recognises this as a date and formats it as “23-Mar-12”. I can select Format Cells and enter or select a custom format or select one of the date formats so I can have any format I can imagine wanting including non-English names for days and months.
However, in one case the format I select is not the format that is recorded: Custom format “dd/mm/yyyy” is recorded as Date format “* 14/03/2001”. This is not obviously a problem until further down the line.
I created a column of dates and times and formatted each with a different custom or standard format. I wrote a macro to extract the NumberFormat for each of these dates and times and write it as a string to an adjacent column. I also formatted the value using the number format and wrote that string to a third column.
In a number of cases the format selected and recorded by Excel was not the format returned by NumberFormat:
Excel format NumberFormat
Date: * 14/03/2001 m/d/yyyy
Date: * 14 March 2001 [$-F800]dddd, mmmm dd, yyyy
Date: 14/03/2001 dd/mm/yyyy;#
Date: 14/03/01 dd/mm/yy;#
Date: 14/3/01 d/m/yy;#
Date: 14.3.01 d.m.yy;#
Date: 2001-03-14 yyyy-mm-dd;#
Date: 14 March 2001 (1) [$-809]dd mmmm yyyy;#
Date: 14 March 2001 (2) [$-809]d mmmm yyyy;#
Custom: hh:mm:ss h:mm:ss
Time: * 13:30:55 [$-F400]h:mm:ss AM/PM
Time: 13:30:55 (1) hh:mm:ss;#
Time: 13:30:55 (2) h:mm:ss;#
Time: 01:30:55 PM [$-409]hh:mm:ss AM/PM;#
Time: 1:30:55 PM [$-409]h:mm:ss AM/PM;#
The values (1) and (2) in the Excel format column were added by me to indicate that there are two apparently identical formats. As can be seen from the NumberFormat column, in each case the second version suppresses a leading zero.
Most changes have no important effect. “[$-F800]” and so on are apparently dummy values with no effect. Apparently you can replace “F800” with an Microsoft country code to have the names of days and months translated to the language of that country.
However, the three standard formats that Microsoft marks with an asterisk are changed unacceptably. The dates are changed from little endian to middle endian; the time is changed from 24 hour to 12 hour and the day of the week has been added to “* 14 March 2001”.
The asterisk against the dates, references the comment: “Except for items that have an asterisk () in the Type list (Number tab, Format Cells dialog box), date formats that you apply do not switch date orders with the operating system.” The asterisk against the time, references the comment: “Except for items that have an asterisk () in the Type list (Number tab, Format Cells dialog box), time formats that you apply do not switch time orders with the operating system.”
If I have to, I can warn my users that standard date and time formats may not give the result desired. However, if they want the popular format “dd/mm/yyyy”, they cannot have it. “dd-mm-yyyy”, for example, is OK but custom format “dd/mm/yyyy” becomes date format “* 14/03/2001” becomes “m/d/yyyy”.
Returning to my opening point: is this strange handling of one particular date format the reason so many people claim their dates are sometimes being converted to American format and is this why the problem is so elusive? I have come across this type of problem elsewhere of one group of Microsoft programmers not knowing what another group are doing. Is this why some functions always work and other sometimes don’t? Some Microsoft programmers know where to look for the correct format and others don’t?
More importantly, for me, can anyone suggest:
How I obtain the true date or time format?
Some other way of determining the user’s chosen display format for a date or time?
BTW 1: I recall that thirty or so years ago I was told that the American military do not use month/day/year format; only American civilians use this format. Can anyone tell me if this is true?
BTW 2: The similar problem is with Excel colours. Excel holds its colours as "ggbbrr" while everybody else holds them as "rrggbb". The programmers for the .Net Excel inter-op were not told and and did not reverse the Excel colour number before using it to control the screen.
I have mainly come up against formatting and date issues when opening text files which have been saved with different regional settings. Two useful cell properties for dealing with this are:
.Text returns the cell value as it is displayed
.Value2 returns the unformatted cell value or date serial number.
As you say, standard date and number formats depend on windows regional settings and this may not be desired behavior as the same workbook can display differently in different regions. MS introduced the regional code prefixes in number formats (circa Excel 2000?) which enforce consistent display if needed but they need to be explicitly selected.
If you really want to see a date or number as the user entered it, you could extract the contents of the .xlsx file looking at the worksheet cell format and the shared strings xml definitions which list the number formats in the saved workbook. I don't really see a need to do this though as the underlying value is stored internally as a serial number and this will not change.
BTW 1: It's been almost 30 years since I was in the military...
I worked on helicopters and I was taught to use a format such as this in the aircraft logbooks: 3 Apr 12. So, that's how I still write dates. This way, there's no wondering about 4/3/2012 - is it April 3 or March 4?
I hacked this: I rewrite the original data in a known format. it relies on DateSerial and TimeSerial:
'Google spreadsheet stores dates in USA format (MM/DD/YYYY). We're in Australia, using DD/MM/YYYY, so we need to swap them.
'
With dc 'the cell who contains a date in USA format.
d = .Value 'capture value in USA format
t = TimeValue(d)
.NumberFormat = "dd/mm/yyyy" 'set to OZ format, so Excel knows the values were swapped in its internal math.
.Value = DateSerial(Year(d), Month(d), Day(d)) 'DateSerial takes y,d,m. We swap Month and Day components, to get OZ format dates
.Value = .Value + TimeSerial(Hour(t), Minute(t), Second(t))
dc.Font.Bold = True ' We bold the cells that are swapped, for debugging
End With
End If
I'm working on a project where I have to parse excel files for a client to extract data. An odd thing is popping up here: when I parse a date in the format of 5/9 (may 9th) in the excel sheet, I get 39577 in my program. I'm not sure if the year is encoded here (it is 2008 for these sheets).
Are these dates the number of days since some sort of epoch?
Does anyone know how to convert these numbers to something meaningful? I'm not looking for a solution that would convert these properly at time of parsing from the excel file (we already have thousands of extracted files that required a human to select relevant information - re-doing the extraction is not an option).
Excel stores dates as the number of days since 0-JAN-1900 (so 1-JAN-1900 would have a value of "1"). You can find a really good breakdown of how Excel handles dates and times here:
Dates And Times In Excel
When dates appear on screen in Excel as "5/9", "May 9th", or some such, it is a trick of the formatting and is not representative of the underlying data value. It sounds like your parsing program is pulling the underlying value, not the formatted date. In order to suggest a fix, though, I need to know what your parsing program is (Excel macro, formula, outside code, etc.).
DateTime.FromOADate (if you're using .NET) is the method you want. Excel dates are stored as doubles. If you have dates in the first two months of 1900 you might get bit by the Excel 1900 leap year bug.
From http://msdn.microsoft.com/en-us/library/system.datetime.fromoadate.aspx:
Double-precision floating-point number
that represents a date as the number
of days before or after the base date,
midnight, 30 December 1899. The sign
and integral part of d encode the date
as a positive or negative day
displacement from 30 December 1899,
and the absolute value of the
fractional part of d encodes the time
of day as a fraction of a day
displacement from midnight. d must be
a value between negative 657435.0
through positive 2958466.0.
All you need to do is format the cells correctly. Or am I misunderstanding your question -- are you saying you want to do it OUTSIDE of Excel? I wasn't sure. I'll delete this answer if it turns out to be stupid.