[Rpm-maint] [rpm-software-management/rpm] Take changelog timezone in account (RhBug 1715412) (#739)

Panu Matilainen notifications at github.com
Fri Aug 23 09:12:59 UTC 2019


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20190823/dd6a7851/attachment.html>


More information about the Rpm-maint mailing list