<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 8, 2019, 09:25 Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2/7/19 9:08 PM, enh via Toybox wrote:<br>
> Add support for more input formats, primarily the ISO formats used by<br>
> the AOSP build.<br>
<br>
Ok.<br>
<br>
> Also, our interpretation of @UNIXTIME was wrong: surprisingly, it should<br>
> respect $TZ.<br>
<br>
That's _insane_.<br>
<br>
Does "date +%s" also adjust for $TZ? If so, it's NOT UNIXTIME. If it does, "date<br>
@$(date +%s)" moves the clock by multiple hours...</blockquote></div></div><div dir="auto"><br></div><div dir="auto">This change certainly produces results consistent with the GNU date, but I suspect it's not "right right". I didn't get to a point where I had working support for input starting `TZ="blah" ` so I backed out what I'd done and sent you this as a "better than yesterday" stop gap. 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?</div><div dir="auto"><br></div><div dir="auto">We'll see when we get there...</div><div dir="auto"><br></div><div dir="auto"></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Rob<br>
</blockquote></div></div></div>