tompbjss
commented
3 months ago 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
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?