[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Info-mtools] mcopy applies local time zone to SOURCE_DATE_EPOCH
From: |
Thomas Schmitt |
Subject: |
[Info-mtools] mcopy applies local time zone to SOURCE_DATE_EPOCH |
Date: |
Thu, 17 Feb 2022 19:54:33 +0100 |
Hi,
during the attempt to make the EFI bootable ISO images of project pcmemtest
reproducible it turned out that mcopy yields different byte-level results
in different timezones, although environment variable SOURCE_DATE_EPOCH is
set to the same value.
This is caused by the use of localtime(3) in function mk_entry() which
interprets the overridden getTimeNow() value against the specification
of SOURCE_DATE_EPOCH at
https://reproducible-builds.org/specs/source-date-epoch/
which says that it holds the number of seconds in UTC.
So in the special case that getTimeNow() is overridden by SOURCE_DATE_EPOCH,
the conversion in mk_entry() of directory.c should be done by
now = gmtime(&date2);
instead of
now = localtime(&date2);
Now i wonder how one would properly transfer from misc.c to directory.c
the information that the "now"-time was overridden.
Two alternative approaches come to my mind:
- Move the interpretation of SOURCE_DATE_EPOCH to config.c and store
the value in two new global variables: A flag and a value.
getTimeNow() would return the value if the flag says that it is valid.
mk_entry() would use gmtime(3) if the flag says "valid".
- Introduce a new function
int haveSourceDateEpoch(int set_to_1)
{
static int have = 0;
if (set_to_1)
have = 1;
return(have);
}
It would be called as haveSourceDateEpoch(1) in getTimeNow() if
SOURCE_DATE_EPOCH is accepted.
It would be called as haveSourceDateEpoch(0) in mk_entry() in order
to decide whether to use gmtime(3).
What does upstream say to these ideas ?
Have a nice day :)
Thomas
- [Info-mtools] mcopy applies local time zone to SOURCE_DATE_EPOCH,
Thomas Schmitt <=