On 31/07/15 07:25, Chris Packham wrote:
> The problem is that date -u implies UTC. So +0000 is right if you do
> want the time to be displayed in UTC (for me living at +12/+13 UTC
> makes my head hurt because all the dates are yesterday).

One of the main problems with human-readable date/time is that it implies a 
calendar, with all its exceptions like leap years, changing DST, etc. Many 
RFCs, and the POSIX date functions, are highly flawed and conflate calendars 
with absolute time, e.g. don't specify they mean the Gregorian calendar, and 
don't specify what to do with dates before when the Gregorian calendar was 

If you want to be precise about these things (so as to not cause problems in 
the future), then you need to specify all of that when dealing with 
human-readable dates. This is why for now, the Reproducible Builds timestamps 
proposal only defines SOURCE_DATE_EPOCH. We might extend it later, though.

> The intent of f3f431a7 was to reflect the timezone that the build
> machine was set to. Dropping the -u would probably be sufficient but
> perhaps it would be better to make whole lot conditional on
> SOURCE_DATE_EPOCH being set. Something like this (untested, apologies
> gmail web interface)
> ifneq ($(SOURCE_DATE_EPOCH),)
> define filechk_timestamp.h
>        LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_DATE "%b
> %d %C%y"'; \
>        LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TIME "%T"'; \
>        LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TZ "%z"' )
> endef
> else
> define filechk_timestamp.h
>        (LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"'; \
>        LC_ALL=C date +'#define U_BOOT_TIME "%T"'; \
>        LC_ALL=C date +'#define U_BOOT_TZ "%z"')
> endef
> endif

Yes, it is best to force the TZ as UTC for now, if SOURCE_DATE_EPOCH is set.

At some point later, we might add SOURCE_DATE_TZOFFSET, or other formats that 
include a timezone offset, or something. (That would match Git's internal 
timestamp format, which is "$epochts $tzoffset", and can be translated 
unambiguously into ISO8601 and RFC2822 formats). For now though, we decided to 
keep things simple. But please say so, if you think that is something you (or 
others who use timestamps in build systems) would really want.

BTW, you need to do "@$${SOURCE_DATE_EPOCH}" when giving timestamps to date(1):

$ date -d @1438330000 +%s
$ date -d 1438330000 +%s
date: invalid date ‘1438330000’



Attachment: signature.asc
Description: OpenPGP digital signature

Reproducible-builds mailing list

Reply via email to