Re: Mismatch between documentation and reality: Valid-Until
On Mon, Jan 09, 2017 at 02:49:04PM +0100, Philipp Kern wrote:
> Hi,
>
> dak and https://wiki.debian.org/RepositoryFormat seem to disagree on the
> definition of the Valid-Until field. dak writes "UTC" as the timezone into
> the Release file, where the repository format references policy 4.4 but
> states that it has to be always in UTC. The example given hence states
> "+0000" as the timezone, which is the only timezone specification allowed in
> the trailer of changelog entries. apt pipes it through a function that
> allows more timezones (RFC1123StrToTime), specifically GMT/UTC/Z are
> hardcoded in it. Is there a particular reason why we need to allow this if
> +0000 denotes the same value? Could we at least document the field properly?
> ;-)
Historical reasons. The function also accepts more date formats than
specified.
>
> I'll also note that policy is slightly ambiguous on how the date is supposed
> to be specified: "dd is a one- or two-digit day of the month (01-31)" --
> This reads to me as if zero padding is required according to the example but
> not according to the text.
It is, but it's not. While a file should use zero padding, it a client
should also accept non-zero padded values.
I added the following clarification to the page:
The time zone must be specified as one of {{{+0000}}}, {{{UTC}}},
{{{GMT}}}, or {{{Z}}}. It should be specified using the first option,
{{{+0000}}}.
The numerical values for day, hour, minute, and second must be zero
padded. Clients should also accept non-zero-terminated values for
historical compatibility reasons.
Clients may accept other formats in addition to the specified one, but
files should not contain them.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Reply to: