From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-19883-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 5130 invoked by alias); 21 Feb 2015 18:23:11 -0000
Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Users List <zsh-users.zsh.org>
List-Post: <mailto:zsh-users@zsh.org>
List-Help: <mailto:zsh-users-help@zsh.org>
X-Seq: 19883
Received: (qmail 10123 invoked from network); 21 Feb 2015 18:23:09 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
	autolearn=ham version=3.3.2
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.1 cv=Pd9IXZlY c=1 sm=1 tr=0	a=FT8er97JFeGWzr5TCOCO5w==:117
 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8	a=oR5dmqMzAAAA:8 a=-9mUelKeXuEA:10
 a=0HtSIViG9nkA:10	a=hL3NhbnX-UTcPwFvyckA:9 a=CjuIK1q_8ugA:10
From: Bart Schaefer <schaefer@brasslantern.com>
Message-id: <150221102305.ZM26540@torch.brasslantern.com>
Date: Sat, 21 Feb 2015 10:23:05 -0800
In-reply-to:
 <CABx2=D9e8KPMd9fxL5UY5BoVOdnNyMx-d2tR3v_4Gmd7V5m7DQ@mail.gmail.com>
Comments: In reply to Kurtis Rader <krader@skepticism.us>
 "Re: Convert UTC time to local time using strftime and zsh/datetime" (Feb 20,
 9:02pm)
References:
 <CADjGqHvaOkB-T_qGHDvt9=8TzSGiR8-FptXCX8VNFyfPkmJN-g@mail.gmail.com>
	<CABx2=D9e8KPMd9fxL5UY5BoVOdnNyMx-d2tR3v_4Gmd7V5m7DQ@mail.gmail.com>
X-Mailer: OpenZMail Classic (0.9.2 24April2005)
To: Zsh-Users List <zsh-users@zsh.org>
Subject: Re: Convert UTC time to local time using strftime and zsh/datetime
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii

On Feb 20,  9:02pm, Kurtis Rader wrote:
}
} TZ=UTC strftime -r "%Y-%m-%d %H:%M:%S +0000" "2015-02-11 16:42:30 +0000"
} 
} Which should yield 1423672950 as the seconds since the UNIX epoch.

Except it doesn't unless you have already done "export TZ", because
strftime is not one of the special builtins that really do alter the
process environment when you prefix them with a variable assignment.
So in my environment where TZ starts out not set, this still returns
the epoch in my local time zone, e.g. 1423701750.

This is guaranteed to fix the timezone issue:

    (){ local -x TZ=UTC;
	strftime -r "%Y-%m-%d %H:%M:%S %z" "2015-02-11 16:42:30 +0000" }

but note that %z to match the timezone is a glibc extension to strptime
and may not work everywhere.

Also note that strptime is not defined to perform timezone conversions;
even though glibc strptime can be told that a timezone is present, it
parses it and then throws it away.  In TJ's original formulation

} > > strftime -r "%Y-%m-%d %H:%M:%S +0000" "2015-02-11 16:42:30 +0000"

the +0000 is just a string which is matched but ignored.  Either way,
this is why the TZ=UTC environment setting is needed.

The next question is whether the strftime builtin should implicitly
perform "local -x TZ" to make Kurtis' example do the expected thing.