[WIP-PATCH v1] Re: SOURCE_DATE_EPOCH library code

[Miguel Ángel Arruga Vivas]

Hi Bruno,

Attached comes a WIP/v1 patch against gnulib master.  I've tested it
together with the v3 patch for gettext from the original thread.

0001-source-date-epoch-New-module.patch
Description: source-date-epoch-v1.patch

Bruno Haible <bruno@clisp.org> writes:

> Hi Miguel,
>
> Moving this part off of the bugtracker <https://savannah.gnu.org/bugs/?59658>.
> [...]
> I can see two relevant documents regarding SOURCE_DATE_EPOCH:
> The documentation <https://reproducible-builds.org/docs/source-date-epoch/> 
> and
> the specification <https://reproducible-builds.org/specs/source-date-epoch/>.
>
> The specification says
>   "A UNIX timestamp, defined as the number of seconds, excluding leap seconds,
>    since 01 Jan 1970 00:00:00 UTC."
> To me, it is thus clear that in the 'source_date_epoch_time' function no
> timezone handling is involved.

Sure, as far as time_t follows POSIX standards that's the case.  I've
left some placeholders because I'm guessing that some of the systems
supported by gettext could need extra bits that usually are no-ops or
statically defined constants, but I cannot test them---my main suspect
(mingw/cygwin) probably will need until next week.  Also, I've borrowed
some inspiration from mktime.m4. :-)

> Whereas for 'source_date_epoch_tm': The documentation of this function should
> state whether it produces a 'struct tm' in local time or a 'struct tm' in
> UTC time. Due to the existence of the functions localtime() and gmtime() in
> ISO C, you cannot know a priori.

You're right, this function wasn't needed at all as both can be called by
client code who can choose better based on their needs.  I've removed it
completely.

> It is good to provide an 'int' as return code and let the application do the
> error reporting.
>
> Does this return code need to carry 4 different cases? The specification says:
>   "... use a timestamp no later than the value of this variable."
>   "If the value is malformed, the build process SHOULD exit ..."
> To me, this sounds as if there are 3 different cases:
>   - The value is provided and valid.
>   - The value is provided and invalid.
>   - The value is not provided.
> When the value is defined to an empty value, it is invalid; that is my
> reading of the specification and of the example code for C.
> POSIX-defined environment variables (such as LANG) with an empty value are
> considered equivalent to an absent value; this is because ages ago, shells
> did not have an 'unset' command that could remove an environment variable
> from the environment. But nowadays, this 'unset' command exists, and
> therefore there is no need any more to treat an empty value like an absent
> value (for things that are not specified by POSIX).

I've implemented this:
  - The value is provided and valid: 0
  - The value is provided and invalid: 1
  - The value is not provided: -1

I've added too a replacement call for time when the result isn't 0, as
it makes gettext integration seamlessly, together with a bit of
documentation.  What do you think?

Best regards,
Miguel