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(a)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
>> 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
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
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:
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. :)