[Toybox] [PATCH] date: some fixes.

[Rob Landley]

On 2/11/19 2:15 PM, enh wrote:
> On Fri, Feb 8, 2019 at 10:18 AM Rob Landley <rob at landley.net> wrote:
>>
>>
>>
>> On 2/8/19 11:54 AM, enh wrote:
>>>
>>>
>>> On Fri, Feb 8, 2019, 09:25 Rob Landley <rob at landley.net <mailto:rob at landley.net>
>>> wrote:
>>>
>>>     On 2/7/19 9:08 PM, enh via Toybox wrote:
>>>     > Add support for more input formats, primarily the ISO formats used by
>>>     > the AOSP build.
>>>
>>>     Ok.
>>>
>>>     > Also, our interpretation of @UNIXTIME was wrong: surprisingly, it should
>>>     > respect $TZ.
>>>
>>>     That's _insane_.
>>>
>>>     Does "date +%s" also adjust for $TZ? If so, it's NOT UNIXTIME. If it does, "date
>>>     @$(date +%s)" moves the clock by multiple hours...
>>>
>>>
>>> This change certainly produces results consistent with the GNU date, but I
>>> suspect it's not "right right".
>>
>> <facepalm>sigh</facepalm>
>>
>>> I didn't get to a point where I had working
>>> support for input starting `TZ="blah" `
>>
>> Starting as in setting the environment variable on the command line...?
> 
> no, that's what i mean by this not being "right right" (i.e. it's a
> local maximum, not the global maximum) ... my patch gets us to where
> we're no worse than busybox, but GNU date actually supports something
> like:
> 
> TZ=Europe/London date -d 'TZ="America/Los_Angeles" @1549649764'

That's even more insane.

Sigh. This is the part of the patch I object to:

-    gmtime_r(&tt, tm);
+    // Somewhat surprisingly, even Unix input times respect $TZ.
+    localtime_r(&tt, tm);

The rest of it I'd have applied already. I'm aware GNU is doing something
stupid, and I understand you have AOSP build issues that depend on the GNU
stupid. I just... I'm facepalming here in real life. There was a loud dramatic
sigh. Out loud.

> where there are two separate time zones in play. (and this is used in
> the AOSP build. there are a couple of [failing] examples in the
> tests.)

Tell you what, lemme rip those 3 lines out of your patch and apply the rest now
to at least get the delta down. I expect I'm just going to have to lump it and
do the stupid thing GNU does because existing scripts depend on The Stupid, but...

How does unix time not mean UTC? How do they implement +s output not using
timezones and @input applying a timezone offset? (Answer: The FSF is bad at
software and cares nothing for consistency. But it still hurts.)

Huh, 4 of your new tests are failing with TEST_HOST=1 ?

FAIL: date -d 06021234
FAIL: date -d 060212341982
FAIL: date -d 1110143115.30
FAIL: date -d 111014312015.30

Hmmm, VERBOSE=fail says...

FAIL: date -d 06021234
echo -ne '' | TZ=Europe/London date -d 06021234 2>&1
--- expected	2019-02-11 23:23:26.734146212 -0600
+++ actual	2019-02-11 23:23:26.738146212 -0600
@@ -1 +1 @@
-Sun Jun  2 12:34:00 UTC 1900
+date: invalid date ‘06021234’

>>> so I backed out what I'd done and sent
>>> you this as a "better than yesterday" stop gap.

I have applied a subset of it. Probably apply the rest tomorrow, but I need time
to mourn first.

This is _really_ stupid. I mean this is from the man page:

EXAMPLES
       Convert seconds since the epoch (1970-01-01 UTC) to a date

              $ date --date='@2147483647'

They SAY the epoch is in UTC and this is seconds since that! Right there in the
man page! They're inconsistent with their own man page!

>>> But I suspect that when we get
>>> to the point where we handle separate input and output timezones, this
>>> presumably goes back to UTC (unless it's preceded by TZ=) and the *output*
>>> conversion produces this effect instead?

*blink* *blink* What?

$ date ; date --date=@$(date +%s)
Mon Feb 11 23:32:21 CST 2019
Mon Feb 11 23:32:21 CST 2019

I don't understand what's going on here. That's what

> but like i say, to be _better_ than busybox we need to take both time
> zones into account, and that probably needs us to stop using `struct
> tm` internally, and do two conversions.

Sigh. Send me a patch to make the AOSP build work and I'll apply it. I don't
have to _like_ it.

But I don't think I currently understand the expected behavior...

$ date ; date --date=@$(TZ=UTC date +%s)
Mon Feb 11 23:33:58 CST 2019
Mon Feb 11 23:33:58 CST 2019
$ date ; TZ=UTC date --date=@$(date +%s)
Mon Feb 11 23:34:15 CST 2019
Tue Feb 12 05:34:15 UTC 2019

No, I _really_ don't understand what's going on here.

>> Rob

Rob