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

[Rich Felker]

On Wed, Jan 25, 2017 at 05:15:37PM -0600, Rob Landley wrote:
> 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.

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

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

Rich