[Toybox] Stat %Z - What are valid values?

[Rob Landley]

On 01/25/2017 06:25 PM, Rich Felker wrote:
>> According to man 2 time:
>>
>>  time()  returns  the  time  as  the  number of seconds since the Epoch,
>>  1970-01-01 00:00:00 +0000 (UTC).
>>
>> I.E. the definition of unix time is UTC. So %s _not_ being UTC is silly.
> 
> Nobody is questioning whether the input read by %s is UTC. The
> question is whether the output struct tm is UTC or local.
> 
>> My use case (and presumably most people's) is turning a time string into
>> a struct timespec. What the actual struct tm fields are is irrelevant to
>> that as long as mktime() translates the result back to the right number.
> 
> mktime interprets it as local, in which case strptime would have to be
> doing the inverse operation, converting from UTC to local for the
> struct tm output.
> 
> On the other hand strptime output may also be used with timegm (or a
> hand-rolled version thereof).

If mktime is in posix and timegm isn't, that probably means something.

People can write hand-rolled code to do anything, doesn't make it right.

> This is what you would do if you were
> parsing a sting in UTC. With all the existing/standard fields,
> strptime is completely agnostic with regards to what you want to do
> with the output. Only with %s will it need a hard-coded assumption
> about what you're going to do with the output.

Not if it's symmetrical. If I don't _change_ the time zone between
populating the struct tm and consuming the struct tm, I should get the
same result back out, which is what I'm trying to accomplish.

>From man timegm:

  For a portable version of timegm(), set the TZ environment variable
  to UTC, call mktime(3) and restore the value of TZ.

I.E. the "portable" behavior is symmetrical if you don't change the
timezone in the middle. If you do, that's obvious pilot error. And if I
want everything to happen in UTC, I can set TZ (which the date command
does for -u already).

>> The struct tm has a timezone field in it. As long as strptime sets the
>> timezone when it adjusts the hours so mktime() can adjust it _back_, the
>> result is the same number you fed into %s. Which is the point of the
>> exercise.
> 
> mktime cannot use the timezone field of struct tm. It's required to
> assume the struct tm is in local time in the current timezone.

As long as it's symmetrical, it works for me. If posix requires mktime
to use the current timezone and that's the _only_ way it provides of
turning struct tm into time_t, then it implicitly requires strptime to
mirror that when turning an ascii representation of time_t into a struct
tm. It needs to do the opposite of what mktime does, so mktime can undo it.

> Rich

Rob