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

DateTime.fromISO() returns invalid date for (some) numbers #1591

Open
codingfabi opened this issue Jan 30, 2024 · 2 comments
Open

DateTime.fromISO() returns invalid date for (some) numbers #1591

codingfabi opened this issue Jan 30, 2024 · 2 comments

Comments

@codingfabi
Copy link

Describe the bug
I have a situation where I want to compare and evaluate user input. The user input can either be a date string or a number. In the resolvement function, I wanted to avert checking the variable type and just parse the input into a date and check whether this parsed date is valid. This works perfectly fine except for numbers between 10 and 24.

To Reproduce
CodeSandbox

Actual vs Expected behavior
I would expect the function to either work with arbitrary numbers or with no numbers at all. This behaviour seems inconsistent.

  • Browser [e.g. Chrome 84, safari 14.0]
  • Luxon version: latest

Additional context
This is more a question than a bug report to be honest. If this behaviour is intended, I am totally fine with it. However, I am primarily wondering why it only works for integers from 10 to 24. I assume/understand that is has something todo with some time offset and I would understand every number larger than 24 not working. However, it still puzzles me that single digit numbers also seem to be a problem. Is there any particular reason behind this?

@tompbjss
Copy link

Hi,
I don't think this is a bug. After looking into the method and the documentation for ISO standard it seems that two digits is a valid representation of just the hour which alone is covered by the standard.

In this case the number is parsed to a string ("9" and "10") so it can be run though a number of regexes to check the format matching the ISO standard. One of these regexes matches on two digit numbers and will try to extract this into a hour.
9 or "9" is not a valid hour but "09" is and similarly "24" is a valid hour while "25" is not.
This explains why 10-24 work but no other numbers do.

The ISO standard mentions two digit hours being valid representation with reduced accuracy for the hour.
This does seem strange for the method but other cutdown representations are supported as per the unit tests so this one does match the pattern.

@charan-notion
Copy link

I have a similar situation where passing the string "19-1128" to DateTime.fromISO returns a valid but wrong date. It seems like the parsing logic is matching "19" for hours unit. What could be the reason for this?

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

No branches or pull requests

3 participants