The problem here is that the cat is out of the bag and people are already using
whatever in their specs. This is a bunch of random ponderings on the subject,
rather than anything definitive on way or the other.
If we limited it to UTC only, then the "UTC" part becomes waste of perfectly
good bytes, we could just as well limit it to the offset only. But anybody who
commonly thinks of their existence in terms of UTC offsets, raise their hands?
Me neither. Worrying about offsets is a task for a computer, not a human. UTC
offsets in the changelog would be absolutely fine if the computer created them,
as is the case with eg git.
>From a human consumer perspective, I liked the tzset() alternative better, due
>to natural timezone names. I was only objecting to the use of tzname[1] which
>doesn't seem reliable source of information at all based on the specification.
> If there really is no way to to coerce glibc to do what we want (ie use human
>timezone names), other alternatives include at least
a) outsource the parsing to something else that can, such as the 'date' command
b) relax the %changelog parsing rules
As for b), failing to parse the spec because somebody typoed a wrong date in
the %changelog is kinda ridiculous really. The natural chronological order of
changes is determined by the *position* in the log, and the purpose of the date
is to give the changes a time *frame*, rather than a precision timestamp (only
of course the new format is just that).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/739#issuecomment-524239301
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
