Re: print builtin preceded by parameter assignment

[Bart Schaefer <schaefer@brasslantern.com>]

On Thu, Apr 11, 2019 at 1:58 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> The actual takeaway here is that TZ has to be pushed into the actual
> environ strings, not just set temporarily as a local to the shell, in
> order for the system time libraries to apply it to strftime et al.

The trick is to mark TZ exported before you try to use it as a prefix
assignment.

% echo $+TZ
0
% export TZ
% echo $+TZ
1
% print -P "%D{%c %Z}"
Thu Apr 11 14:27:39 2019 PDT
% TZ=UTC print -P "%D{%c %Z}"
Thu Apr 11 21:27:58 2019 UTC

Here's a semi-related oddity -- once the timezone is changed, it does
not change back, even though the TZ variable is not set:

% echo $TZ

% date
Thu Apr 11 21:28:18 UTC 2019

Oops, the timezone remains UTC even though the variable is no longer
set.  This has to be a side-effect of calling localtime() in
promptexpand().  Explicitly resetting TZ fixes it:

% export TZ=PST8PDT
% date
Thu Apr 11 14:29:25 PDT 2019

Also, once TZ is both marked for export and has a valid value,
everything works the way Vincent expects:

% TZ=UTC print -P "%D{%c %Z}"
Thu Apr 11 21:29:36 2019 UTC
% date
Thu Apr 11 14:29:43 PDT 2019
%

So the "bug" if there is one is that variables that aren't marked for
export don't magically become exported when used before a builtin in a
prefix assignment.

As an aside, TZ is explicitly referenced and manipulated when using
zsh/datetime strftime builtin, so it might not suffer from any of
these problems.  I haven't tested it