You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
The text was updated successfully, but these errors were encountered:
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.
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?
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.
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?
The text was updated successfully, but these errors were encountered: