summaryrefslogtreecommitdiff
path: root/test/integration/test-bug-718329-support-data.tar-uncompressed
diff options
context:
space:
mode:
authorDavid Kalnischkies <david@kalnischkies.de>2016-07-02 11:28:42 +0200
committerDavid Kalnischkies <david@kalnischkies.de>2016-07-02 12:01:17 +0200
commit0b45b6e5de1ba4224ced67a9952e009d0f4139a0 (patch)
tree60e8192a59d3999af3b79af62136de4ba7d310a6 /test/integration/test-bug-718329-support-data.tar-uncompressed
parentf4dcab0504a68595d9e95c953ce66f46f9ad30aa (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-bug-718329-support-data.tar-uncompressed')
0 files changed, 0 insertions, 0 deletions