Time strings like `21:00` parsed as integers due to YAML 1.1 sexagesimal support

[brege]

I'm using confuse to communicate between YAML config files and my app's API. I've been using the opinionated 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:

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, 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:

some_time: 21-00  # Parsed as string '21-00', yamlfix preserves it

then,

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.

[semohr]

I believe adopting the 1.2 specification is the right path forward. There was even some initial effort on this in #145.