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

[Rob Landley]

On 01/24/2017 06:10 PM, Rich Felker wrote:
>>> strptime with %s? I suspect there are some nasty underspecified issues
>>> with how it interacts with timezones.
>>
>> I thought unix time was always UTS and the timezone just affected how it
>> was displayed?
> 
> The problem is that strptime produces a struct tm. When the fields
> it's parsing to produce this struct tm are "broken down time" fields,
> strptime does not need to know/care whether the caller is going to
> interpret the struct tm as UTC or local time; it's just a bunch of
> numbers. But when strptime is going to take a unix time value (seconds
> since epoch) and convert it to struct tm, it matters whether the
> caller is supposed to treat that struct tm as UTC or local.

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.

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

(Remember when Linux systems used to have a "store system clock in GMT
instead of localtime" option during config, and the config option went
away because nobody ever _didn't_ do that? Yeah, that.)

> Rich

Rob