Time strings like `21:00` parsed as integers due to YAML 1.1 sexagesimal support
- Dominant language
- Python
- Stars
- 424
- Forks
- 57
- PR merge metrics
- No merged PRs in 30d
Description
I'm using confuse to communicate between YAML config files and my app's API. I've been using the opinionated [yamlfix](https://github.com/lyz-code/yamlfix) formatter as a pre-commit hook to keep my config tidy. This YAML formatter removes almost all quotes.
I discovered that confuse interprets unquoted `HH:MM` time strings as sexagesimal (base-60) integers rather than strings:
```yaml
some_time: 21:00 # Parsed as integer 1260 (21×60 + 0)
some_time: "21:00" # Parsed as string "21:00" (then yamlfix removes quotes)
```
I see that confuse uses PyYAML's SafeLoader which then supports only YAML 1.1. In 1.1, colon notation `XX:YY` is interpreted as sexagesimal (base-60) numbers.
Sexagesimal support was removed in the YAML 1.2 specification (2009), and **PyYAML never implemented YAML 1.2 (see [yaml/pyyaml#116](https://github.com/yaml/pyyaml/issues/116), open since 2017).
**Question.**
Is the continued use of YAML 1.1 an intentional design choice, or mainly a limitation inherited from PyYAML?
Working with confuse has been spectacular so far, so I was a little surprised the YAML spec isn't as modern to the degree the library is.
---
The remaining is my workaround:
If I format time as `HH-MM` format instead of `HH:MM`:
```yaml
some_time: 21-00 # Parsed as string '21-00', yamlfix preserves it
```
then,
```python
time_str = config['some_time'].get() # a string '21-00'
time_colon = time_str.replace('-', ':') # '21:00'
# or parse the string directly
from datetime import datetime
time_obj = datetime.strptime(time_str, '%H-%M').time()
```
It took me longer than I like to admit to figure this out, and DuckDuckGo didn't help. This isn't `confuse`'s problem, per se, as `yamlfix` was built on YAML 1.2 from the beginning I believe.
"confuse time string integer"
"yaml 21:00 parsed wrong"
"yamlfix confuse time"
"yamlfix confuse 'HH:MM'"
"confuse colon time"
Given track lengths I guess I never considered HH:MM or MM:SS to be of significant issue.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.