On Fri, Feb 8, 2019 at 10:18 AM Rob Landley <[email protected]> wrote: > > > > On 2/8/19 11:54 AM, enh wrote: > > > > > > On Fri, Feb 8, 2019, 09:25 Rob Landley <[email protected] > > <mailto:[email protected]> > > 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
