The kind of support I thought/hoped that musl would provide has to do
with localtime() for applications that need to deal with, well, local
time.
Yes, that would be the userland way to do it, but even that is not so
simple. To give you an example: when you have a right/ timezone,
the glibc localtime() interprets the system clock as TAI-10, but the
glibc gmtime() interprets it as UTC ! And it even makes sense, in a
certain way, but it's still ugly as hell.
The system time should be TAI10! Any other choice is a commitee
produced abomination. Unless I misunderstood, what is the good reason
for not supporting it, other than being difficult or heavy?
It's not standardized.
The standard is broken, I totally agree, and encourages bad practices;
nevertheless it's the standard, and as a libc, musl cannot afford to
break it.
A part of the difficulty is finding a way to fit into the cracks in
the standard, to do things without explicitly breaking it. That is why
the glibc does what it does.
Another part of the difficulty is doing things cleanly. musl is very
adamant on cleanliness - that's why I like it - and will not implement
extensions if they're not extremely well designed, and putting leap
seconds into the timezone files is definitely bad design. I have full
powers to submit patches to musl that are "correct", and I have a pretty
good idea of what "correct" means for Rich and folks - it's close enough
to my own use of the word.
And so far, I've found that the most "correct" way of handling the
issue is kernel support.
--
Laurent
