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
I think this might be a bit too flexible. If I read it correctly a string such as 2 times 11 is 22 would successfully parse into 02:11:22. I would expect an error and would consider that "successful" result surprising.
When this flexibility is needed I would suggest adding the behavior via sub-classing or monkey patching.
Proposal
Currently, the only separator permitted by the parser is a colon (
:
)How do you feel about making the parser more flexible by allowing any non-digit character to be treated as a seperator?
Rationale
I work in the rail transport sector and railway timetables can contain a whole variety of separators, each with their own meaning:
08.00
- Regular passenger train08+00
- Empty coaching stock08S00
- Stop for staff pick up / set down only08RM00
- Train will make a reversing move. (Depart in the same direction it arrived)I'm sure there are other areas, including user input via html forms, where greater flexibilty might be beneficial.
Allowing any separator will make parsing any data more flexible and simpler.
Problems
The change could possibly break clients that rely on
Tod
parsability to validate data that must only use a colon as a seperatorThe text was updated successfully, but these errors were encountered: