[Toybox] [PATCH] date: some fixes.

[enh]

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'

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

> > so I backed out what I'd done and sent
> > you this as a "better than yesterday" stop gap.
>
> I'm writing up release notes with what I've got, and can try to catch up with
> additional todo items over the weekend. Unfortunately I was out sick half a day
> yesterday, and am only back in today because of deadlines. :P
>
> > 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?
>
>   $ date +%s
>   1549649764
>   $ TZ=UTC date +%s
>   1549649767
>   $ date
>   Fri Feb  8 12:16:50 CST 2019
>
> Hmmm... My $TZ variable isn't set, but:
>
>   $ TZ=UTC date +%s
>   1549649848
>   $ TZ=CST date +%s
>   1549649851
>
> date +%s is not listening to TZ on ubuntu.

no, i was talking about the _parsing_ of Unix time, not the current
time. (i added a test for the case that was wrong before and right
now.)

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.

> Rob