On Thu, 20 Sep 2007 16:16:39 -0400, Bill Nottingham wrote:
Peter Jones (pjones redhat com) said:
Bill Nottingham wrote:
Michael Schwendt (mschwendt.tmp0701.nospam@arcor.de) said:
The changelog times are not stored as date strings in the binary RPM header, but most likely are preconverted to ordinary time() values by rpmbuild, assuming arbitrary values for the missing h:m:s (possibly 0:0:0).
They're stored as seconds-since-the-epoch - see CHANGELOGTIMES in an rpm query.
And more specifically, the date in the specfile is interpreted as noon on that day, UTC.
noon is midday, but Midnight Commander displays 00:00:00 for the changelogs. (perhaps that's another bug in mc, though)
... which means you *shouldn't* be able to get an off-by-one-date, barring being located in the South Pacific and weirdness with leap seconds.
Since there is no time zone specified in the changelog, the off-by-one error *could* be the result of interpreting and converting the specfile in different time zones, not accounting for a change in the weekday if the implicit time zone offset is large enough.
Contrary to my first post in this thread, I *currently* don't get the off-by-one error for "sylpheed", but for e.g. "yum" (Sep 10 -> Sep 11) and (Sep 11 -> Sep 12).
With sylpheed I don't see a time zone offset that is large enough and which would cause a constant off-by-one error:
http://koji.fedoraproject.org/koji/buildinfo?buildID=15872
build-job started: Fri, 24 Aug 2007 04:10:10 MST that is UTC-7 for Phoenix/AZ (or UTC-5 for Raleigh/NC) in Germany it is UTC+1 plus daylight-saving specfile also contains "Fri 24 Aug" => the time zone difference of +8/+9 hours (for AZ) doesn't matter, => it doesn't change the weekday
Even for Fri 24 Aug 12:00 UTC-7, the converted time() value would end at Fri 24 Aug 20:00 UTC+1 when converted back.
For the yum and metacity builds, the offset is even less (<= 2 hours inside the U.S.), but still they are off by one here currently. :)