Enterprise: Locale: parseDate() does not return a valid leap year for leap day (February 29)

Created on 5 Sep 2019  路  5Comments  路  Source: infor-design/enterprise

Describe the bug
Soho.Locale.parseDate() does not return a valid leap year when parsing a date format of month (Soho.Locale.calendar().dateFormat.month), meaning a format such as 'MMMM d' or 'MMdd' when the value is 'February 29' or '0229'. In this situation, the year is not part of the value or format, so it appears that the current year is used causing the resulting value to be 'March 1' or '0301'.

To Reproduce
Steps to reproduce the behavior:

  1. Go to http://localhost:4000/components/datepicker/example-anniversary-format.html
  2. Click on the date picker icon for the Month Day field and select February 29 2016
  3. February 29 will initially display
  4. Tab out of the field and March 1 displays

Additionally, using the browser console to reproduce the behavior:

  1. Enter > Soho.Locale.parseDate("0229", "MMdd", false)
  2. Response > Fri Mar 01 2019 00:00:00 GMT-0600 (Central Standard Time)
  3. Enter > Soho.Locale.parseDate("February 29", "MMMM d", false)
  4. Response > Fri Mar 01 2019 00:00:00 GMT-0600 (Central Standard Time)

Expected behavior
Since February 29 is a special date in the Gregorian calendar and for these examples the year is not specified, the expectation is the date is returned with a valid leap year.

Version

  • ids-enterprise: v4.21.0-dev

Screenshots
image
leap-day

Platform
All

Additional context
For Landmark, any leap year would be ok to use. Another idea might be the closest previous leap year from the current year.

[3] customer landmark type

Most helpful comment

@tmcconechy For the example I gave, I was not expecting 2016 specifically to be returned, but I am expecting a leap year to be returned. The changes @deep7102 has for getting the closest leap year is fine.

All 5 comments

@fitzorama

Enter > Soho.Locale.parseDate("0229", "MMdd", false)
Response > Fri Mar 01 2019 00:00:00 GMT-0600 (Central Standard Time)

Since February 29 is a special date in the Gregorian calendar and for these examples the year is not specified, the expectation is the date is returned with a valid leap year.

Concerning this comment. Not sure i understand. I think what it will do now is assume correct year if none is specified. I think this makes sense. Why would it return 2016? Or is that not what your saying?

@tmcconechy For the example I gave, I was not expecting 2016 specifically to be returned, but I am expecting a leap year to be returned. The changes @deep7102 has for getting the closest leap year is fine.

@jbrcna have a new look master was not correctly updated. this fix is there now

Was this page helpful?
0 / 5 - 0 ratings