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 

- 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

$ 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)



Attachment: signature.asc
Description: OpenPGP digital signature

Reproducible-builds mailing list

Reply via email to