SOURCE_DATE_EPOCH and timezone with FAT images

[Chris Lamb]

Hi,

> * Producers of FAT cannot avoid formatting of SOURCE_DATE_EPOCH to
>   Year/Month/Day/Hour/Minute/Second fields.

To those on this list unfamiliar with the FAT filesystem, this is
worth underlining. Instead of the usual "UNIX epoch" method of storing
a timestamp (as in, a single integer field containing an offset from
an arbitrary start time), the FAT filesystem has separate fields for
year, month, day, hour, minute and second. The actual implementation
is a little more complicated, of course, but this is the key distinction.

(Crucially, unlike an epoch, any multi-field calendrical scheme cannot
help but implicitly encode a timezone; it cannot be agnostic.)

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

So, I might be missing something important about how EFI booting works
and this "MUST" is indeed kinda scary to read, but I don't feel any
fundamental tension here between the SOURCE_DATE_EPOCH spec and what
we are both trying to achieve.

Regardless of the precise wording in the specification, 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?

The conversion into the user's timezone would then, as the spec says,
"deferred until runtime". As in, it is parsed at runtime "as if" it
were UTC, and then converted into the user's own locale and timezone,
if or when it needs to be displayed.

> If this is correct, then I think there should be an explicit timezone rule
> for reproducible images in formats like FAT, where it seems to be custom
> to record timestamps in the local timezone.

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. Putting it another way, "Formatting MUST..." is
surely short for something like "Formatting [of the timezone-agnostic
SOURCE_DATE_EPOCH-like value]...", and any multi-field FAT timestamp
is, as mentioned, not timezone-agnostic to begin with.

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.

> When trying to convince programmers of the additional complexity it does
> not really help that
>   https://reproducible-builds.org/docs/source-date-epoch/
> says:
>   "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. If I
recall correctly, this was intended as a rejoinder and rebuttal to the
idea of a "SOURCE_DATE_EPOCH_TIMEZONE". I believe we felt it necessary
to make this anti-feature explicit; when the spec was being drafted,
demands for a parallel side channel to encode a timezone were based on
various misunderstandings surrounding the whole concept — ideas that
are unrelated to the topics discussed in this thread.

(This has, therefore, been a good lesson that such "clever" asides can
age poorly, and are liable to misinterpretation in the future.)


Regards,

-- 
      o
    ⬋   ⬊      Chris Lamb
   o     o     reproducible-builds.org 💠
    ⬊   ⬋
      o