Re: [Info-mtools] mcopy applies local time zone to SOURCE_DATE_EPOCH

[Alain Knaff]

Hi Thomas,

On 17/02/2022 19:54, Thomas Schmitt wrote:
> 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.

Weird, I just had a look at that page, and elsewhere it seems to imply
that SOURCE_TIME_EPOCH should be formatted in the user's timezone:

   Formatting MUST be deferred until runtime if an end user should
   observe the value in their own locale or timezone.


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

Should it? I guess it depends on which part of the document you give
more weight...

> 
> 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".

This silently assumes that mk_entry is only ever called with current
time (or time faked with SOURCE_DATE_EPOCH). However, if preserveTime is
set, it might be called with the timestamp of the source file, and in
that case, it should be formatted with localtime rather than gmtime.


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

Same issue. It would mess up time formatting in case the time being
formatted is not the current time (or current time faked via
SOURCE_DATE_EPOCH).

Properly implementing this would need to add a parameter to mk_entry to
tell it whether to format the time as UTC or as local time, and it would
be the *caller* of mk_entry which would call this haveSourceDateEpoch as
appropriate. Or in some cases, it would be the caller of the caller...

> 
> What does upstream say to these ideas ?

IMHO, all this introduces way too much complexity for a use case which
is rather niche. Why can't the pcmemtest project just set the TZ
environment variable to UTC? After all, if your build process calls the
"date" utility, you would have to do the same.

> 
> 
> Have a nice day :)
> 
> Thomas
> 

Regards,

Alain