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

[Rob Landley]

On 12/30/2016 04:01 PM, enh wrote:
> On Fri, Dec 30, 2016 at 1:51 PM, Rob Landley <rob at landley.net> wrote:
>> On 12/30/2016 01:39 PM, enh wrote:
>>> 1928-04-26 17:31:55.746667836 18446744072394174731
>>
>> Really we can partially blame posix here for not specifying whether
>> time_t is signed or unsigned. (If it's unsigned it can't represent times
>> before January 1, 1970, as the code on the left is doing. And there
>> _are_ times before then. So I think we have to treat it as signed and go
>> "32 bit timestamps gotta go away before 2038".)
> 
> if you want to be amused/horrified, you should look at the tzcode
> stuff. iirc they only recently agreed that time_t is an integral type.

Note to self: it's easier to review patches after a while if you include
the test case of the thing it fixes in the patch.

Right, this thread...

> Or if it's signed, that's -1346458162 which would be... sometime in the
> 1930's? hmmm... "./date -D %s -d -1346458162" is failing under glibc,
> and failing _differently_ under musl. (Wheee.)
> 
> /me goes down tangent rathole debugging why.
...
> 
> (Answer: musl doesn't implement %s at all, and glibc doesn't allow the
> %s value it converts to be negative.)

Query: does bionic strptime() handle %s, and if so does it handle
negative input values? (If not I suppose I can try to special case this
in toybox, but ew.)

Also, Rich: any interest in adding this to musl?

> with 64-bit toybox:
> 
> angler:/ # date 060200002064
> Mon Jun  2 00:00:00 GMT 2064

Under Ubuntu 14.04 with 64-bit glibc, that becomes

  $ ./date 060200002064
  date: bad date '060200002064'; Fri Jun  2 00:00:00 CST 2064 != Mon
  Jun  2 01:00:00 CDT 2064

So it's adjusting it for daylight savings time, and breaking.

Sigh. _Why_ are we doing this date normalization checking thing again?
It's kinda brittle. I'm starting to remember why this got pushed onto
the todo stack. (Which is really a todo heap with a leaking problem.)

Rob