On 04/06/15 19:30, Daniel Kahn Gillmor wrote: > What TZ should SOURCEDATE have? ISO8601 is capable of supplying a TZ as > well, so the current time could be written in a wide variety of ways > while meaning the same instant: > > 0 dkg@alice:~$ date '+%FT%T%z' && date -u '+%FT%T%z' > 2015-06-04T13:25:25-0400 > 2015-06-04T17:25:25+0000 > 0 dkg@alice:~$ > > I feel like we should we always set it to UTC, so that the inbound > parsed offset would be +0000. sound sensible? >
I had thought about this a bit, and not yet decided the best way - hence why I haven't yet written this idea up on the Debian Wiki. FWIW, here are my thoughts: - Always setting it to UTC would be "simplest", but then our format wouldn't be ISO8601 - we'd have to say "ISO8601 but omit the offset / ignore any offset". RFC 2822 and 3339, the other formats mentioned in `man date`, also include an offset. - It's neater to keep the TZ-offset the same as in debian/changelog. Generated dates will then be consistent with debian/changelog. If debian/changelog says "Mar 2015", then the generated documentation will say "Mar 2015". - However, it seems awkward to get date(1) to preserve the original offset. I suppose this is an artefact of using localtime(3) as you mentioned. In general the libc time stuff seems to have disastrous behaviour if you want to play with time zones other than local time or UTC, and this affects some other languages like python. - One can maybe hack around it with the TZ envvar, but it has a very weird syntax [1], and the hack is dependent on the actual value: $ date -d "2015-06-04T20:18:13+0800" --iso-8601=seconds 2015-06-04T14:18:13+0200 # nope, my local TZ is different $ TZ="UTC+08" date -d "2015-06-04T20:18:13+0800" --iso-8601=seconds 2015-06-04T04:18:13-0800 $ TZ="UTC-08" date -d "2015-06-04T20:18:13+0800" --iso-8601=seconds 2015-06-04T20:18:13+0800 # argh, TZ expects the opposite sign [1] http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html - A possible workaround is to advise people to just extract the information directly out of SOURCEDATE using a regex (or strip off the last 5 chars of SOURCEDATE before giving it to localtime, maybe). But such advice is extra mental work for developers who may not bother reading the document that we put such advice on. >> It would be awesome for help2man to support this. > > help2man (and any other tool that accepts $SOURCEDATE) would also need > to ensure that it extracts the parts it wants in a TZ-independent > fashion as well. (not parsing back to localtime) > X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
