diff options
author | David Kalnischkies <david@kalnischkies.de> | 2016-07-02 11:28:42 +0200 |
---|---|---|
committer | David Kalnischkies <david@kalnischkies.de> | 2016-07-02 12:01:17 +0200 |
commit | 0b45b6e5de1ba4224ced67a9952e009d0f4139a0 (patch) | |
tree | 60e8192a59d3999af3b79af62136de4ba7d310a6 /test/integration/test-cachecontainer-architecture-specification | |
parent | f4dcab0504a68595d9e95c953ce66f46f9ad30aa (diff) |
use +0000 instead of UTC by default as timezone in output
All apt versions support numeric as well as 3-character timezones just
fine and its actually hard to write code which doesn't "accidently"
accepts it. So why change? Documenting the Date/Valid-Until fields in
the Release file is easy to do in terms of referencing the
datetime format used e.g. in the Debian changelogs (policy ยง4.4). This
format specifies only the numeric timezones through, not the nowadays
obsolete 3-character ones, so in the interest of least surprise we should
use the same format even through it carries a small risk of regression
in other clients (which encounter repositories created with
apt-ftparchive).
In case it is really regressing in practice, the hidden option
-o APT::FTPArchive::Release::NumericTimezone=0
can be used to go back to good old UTC as timezone.
The EDSP and EIPP protocols use this 'new' format, the text interface
used to communicate with the acquire methods does not for compatibility
reasons even if none of our methods would be effected and I doubt any
other would (in these instances the timezone is 'GMT' as that is what
HTTP/1.1 requires). Note that this is only true for apt talking to
methods, (libapt-based) methods talking to apt will respond with the
'new' format. It is therefore strongly adviced to support both also in
method input.
Diffstat (limited to 'test/integration/test-cachecontainer-architecture-specification')
0 files changed, 0 insertions, 0 deletions