Comment by tialaramex
1 day ago
I have no doubt that C "explicitly supports" this, but it's a bad idea.
The C standard library has the excuse that most of it is very old. We should do better.
1 day ago
I have no doubt that C "explicitly supports" this, but it's a bad idea.
The C standard library has the excuse that most of it is very old. We should do better.
Better for whom? If you want a dead-simple time type, use time_t.
There are plenty of improvements needed in the C time APIs, like sub-second precision, thread safety, and timezone awareness. What benefit is there to making the struct fields unsigned beyond some arbitrary purity test? This is still C, there are still plenty of ways to make invalid values. And it is nice to be able to subtract as well as add.
Heck, there's no way to encode the full Gregorian Calendar rules in the type system of any language I've ever used, so every choice is going to be a compromise. February 29 Not-A-Leap-Year and April 31 are still invalid dates even if you can outlaw January 0 and March 32.
Making all the fields in struct tm signed ints is clearly there to allow them to be manipulated and consistently so, since other types would obviously be better for size if nothing else.