Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More restrictive fuzzydate #2502

Closed

Conversation

steviegalluscio
Copy link

This change makes the fuzzydate function more restrictive. The changes are:

  • For dates without a month name, only dates with two valid separators(/ - .) are allowed.
    ex. 1/2 is no longer assumed to be a date where as 1/2/0 is acceptable.
    dates with spaces as a separator are not assumed to be dates such as 1 2 0
    Note: 1 / 2 / 0 is acceptable
    Also fixes AUD 76.09 from a comment on issue [0.15.1] Text being converted to dates #1636 will no longer be parsed as a date.

  • Values such as 05.030.2713 will no longer be accepted as dates because of the month having 3 digits (a total of > 10 digits) problem with numeric formatting with CSV file. #2485

I have seen many issues created over fuzzydate and while raw parsing is a workaround, many people want other numeric values preserved and by default. This is a proposed solution by dropping support for mm/dd, mm/yyyy, mm.yyyy etc.

I assume support for dates with a space separator is necessary so let me know if it's worth continuing in this direction. An issue not addressed by this solution is the automatic date conversion of values with two decimal points such as: 3.5.2. Values like these are often used for software versioning. I would prefer not to have to use decimal separator with dates as it's much less common but was curious if any other spreadsheet software uses this standard.

allows only valid dates with two separators or with a typed month
@reviewher
Copy link
Contributor

Please leave feedback in the issue #1300 first (explaining in words what you think is an acceptable date)

@SheetJSDev
Copy link
Contributor

There are some interesting ideas here, but it seems to invalidate common Date+Time strings. For example, consider the date time string 02/02/2022 02:02:02 AM. This is a valid V8 date:

new Date("02/02/2022 02:02:02 AM");
// Wed Feb 02 2022 02:02:02 GMT-0500 (Eastern Standard Time)

This is rejected by the string length test:

 "02/02/2022 02:02:02 AM".replace(/\s+/g, "").length
// 20

Excel recognizes 02/02/02 02:02:02.222 AM as a valid datetime (it assumes the format mm:ss.0 by default, but you can change the number format to something like yyyy-mm-dd hh:mm:ss.000 to see that it extracted the correct value)

@SheetJSDev SheetJSDev closed this Feb 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants