Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend %changelog to support full timestamps (#903) #93

Conversation

pavlinamv
Copy link
Contributor

The newly accepted date format is

Mon Jan 6 09:02:22 CEST 2016

(like output of "date" command). Original format "Mon Jun 6 2016" is still supported.

Resolves: http://www.rpm.org/ticket/903

Copy link
Member

@Conan-Kudo Conan-Kudo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

@pmatilai
Copy link
Member

pmatilai commented Oct 7, 2016

NAK, requires further work as the new format leaks timezone and year into the name field, see http://lists.rpm.org/pipermail/rpm-maint/2016-October/004571.html for details.

…#903)

The newly accepted date format is

Mon Jan 6 09:02:22 CEST 2016

(like output of "date" command). Original format "Mon Jun 6 2016" is still supported.
@Conan-Kudo
Copy link
Member

Conan-Kudo commented Oct 10, 2016

@pavlinamv Would it be possible to support the date+time format where the year comes before the time? It's rather strange to see the year mentioned after the time.

For example, your example date would be structured as:

Mon Jan 6 2016 09:02:22 CEST

This is much more logical than the standard date form and matches how RPM renders date stamps currently when doing something like rpm -qi <package>.

@pmatilai
Copy link
Member

pmatilai commented Oct 11, 2016

Strange/logical is in the eye of the beholder, git also places year after the time (but puts timezone in the end). As for me, my eyes are so used to seeing that format that having the year in the middle seems weird. Ditto for the timezone. Bike-shedding will not get us anywhere, so unless somebody comes up with concrete pro/con reasons, any format is as good as the other. Which is why I'd actually prefer a macro configurable format.

@Conan-Kudo
Copy link
Member

@pmatilai It would also be a pure extension of the existing changelog date stamp, as it would purely append new data in the date stamp, rather than mix it up a bit.

@ffesti
Copy link
Contributor

ffesti commented Oct 11, 2016

Thanks you very much for the patch, your patiences and the additional effort trying to implement the parsing strptime().

Merged.

@ffesti ffesti closed this Oct 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants