After testing I see there is still an issue with single digit months e.g. "Date Format" is 'M/d/yy' the following text '1/1/18' is being inferred as a STRING and not a DATE:M/d/yy but per DateTimeFormatter that is parseable as a date.
On Wed, Jul 17, 2024 at 2:12 PM Dan S <dsti...@gmail.com> wrote: > I believe I found the answer to my question with the following post > DateTimeFormatter > Support for Single Digit Day of Month and Month of Year > <https://stackoverflow.com/questions/27571377/datetimeformatter-support-for-single-digit-day-of-month-and-month-of-year> > From there it seems that java.time.format.DateTimeFormatter (the > underlying class used for parsing the date) has a subtle distinction > between the use of 'MM' and 'M' and between the use of 'dd' and 'd'. The > use of double letters indicate single digits must be padded with a zero but > the use of single letters allow for single digits without padding and > double digits. > > On Mon, Jul 15, 2024 at 5:39 PM Dan S <dsti...@gmail.com> wrote: > >> I am noticing in a unit test when ExcelReader' "Date Format" property is >> configured with MM/dd/yy and the schema access strategy is configured with >> "Infer Schema" that >> a Excel spreadsheet which has a column of data which have dates without a >> leading 0 in the month (e.g 9/18/18) is being inferred as a STRING and not >> a DATE:MM/dd/yy. Only if the month is a double digit (e.g. 10/22/18) it is >> being referred to as DATE:MM/dd/yy. Even if the "Date Format" is >> configured with a single character for month (M/dd/yy) only the double >> digit month is being inferred as a DATE:M/dd/yy and not the single digit >> month. I am also seeing similar behavior when the day is a single digit >> (e.g. 10/5/18) is being interpreted as a STRING and not a DATE:MM/dd/yy or >> DATE:M/dd/yy. >> This does not seem correct. Please advise. >> >> >>
