SOURCE_DATE_EPOCH and timezone with FAT images

[Thomas Schmitt]

Hi,

Bernhard M. Wiedemann wrote:
> What is that "additional complexity" you speak of?

The maintainer of mcopy, Alain Knaff, answered my proposal to let
the existence SOURCE_DATE_EPOCH cause the us of gmtime(3) instead
of localtime(3):

  "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?"
  https://lists.gnu.org/archive/html/info-mtools/2022-02/msg00002.html

The problem is that the function for formatting timestamps currently
does not know that SOURCE_DATE_EPOCH overrode the now-time.
mcopy option -m causes that file times from hard disk get into the FAT
filesystem. The users with DOS background expect those times to be
represented in local time. I guess the Linux kernel expects the same.
(I myself came from HP BASIC and thus wonder why time_t starts in 1970
rather than in year -4712.)


> The most practical approach is to add to the build scripts
> export TZ=UTC

John Neffenger wrote:
> The only sensible solution in this cases is to store the value as an instant
> in UTC time.

Chris Lamb wrote:
> surely the true spirit of the SOURCE_DATE_EPOCH spec can easily be
> adhered to by generating and storing FAT timestamps as if they were UTC?

It is indeed obvious that UTC is the time zone which build software of
reproducible software should apply, if not avoidable.


> Naturally, I appreciate any dedication to follow specifications down
> to the letter, but I don't the above scheme violates it and therefore
> needs an exception.

But in my discussion with Alain Knaff it would be a strong argument if
i could point to a clear statement that at build time SOURCE_DATE_EPOCH
must be formatted to FAT timestamps with timezone UTC.

After all the program already knows SOURCE_DATE_EPOCH. It was just not
foreseen back then that the change would also have to care for the
localtime(3) call in directory.c, function mk_entry.
  https://lists.gnu.org/archive/html/info-mtools/2018-10/msg00003.html


> I *would* be in favour of an implementation note being added to the
> spec to help clarify these kinds of cases, but I would also point out
> these multi-field formats are relatively rare.

I can add ISO 9660 to the list of formats which store timestamps in
a Year/Month/Day/Hour/Minute/Second format.
Unlike FAT, there are Timezone fields so that the timestamps can be
unambiguously converted forth and back to time_t. Nevertheless it spoils
reproducibility if a local timezone is chosen to represent a timestamp.

(xorriso uses GMT by default, because not all readers of ISO 9660
interpret timezones the same correct way. At offset +0000 all bugs hide
in their holes.)

How about expanding

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

to

  Formatting MUST be deferred until runtime if an end user should observe
  the value in their own locale or timezone. If application of a timezone
  cannot be avoided at build time, then it MUST be UTC. This applies to all
  time values, not only to SOURCE_DATE_EPOCH.

Yes, this is somewhat redundant, because the second sentence can be deduced
from the old one if one is willing to apply enough mathematical logic.
I confess that the third sentence is courageous. But it seems necessary
in order to fulfill the overall purpose.


I quoted https://reproducible-builds.org/docs/source-date-epoch/:
> >   "At present, we do not have a proposal that includes anything
> >    resembling a "time zone"."

> Oh yeah, that does sound a little unhelpful out of context today.

How about:

  We demand to apply timezone UTC whenever a timezone is involved in
  formatting timestamps at build time. Beyond this demand, we currently
  do not have a proposal that includes anything resembling a "time zone".


Have a nice day :)

Thomas