On 17/03/16 17:38, Paul Eggert wrote:
> On 03/16/2016 08:51 PM, Assaf Gordon wrote:
>> I suspect it has something to do with this commit:
>> commit 037e3b9847feb46cf6b58d99ce960d3987faaf52
>
> You're right, and thanks for that detailed bug report. I installed the
> attached patch, which fixed the bug for me.
This introduced a bug unfortunately due to the side effects of parse_datetime().
parse_datetime resets the TZ env variable but doesn't call tzset().
Hence using the wrong timezone for output.
Previously localtime() called tzset() implicitly.
Perhaps we should call tzset() in parse_datetime() if needed?
I'm not sure as to whether this undoes the fix for bug 23035?
Anyway this avoids the issue on GNU/Linux.
diff --git a/src/date.c b/src/date.c
index ddc702f..1be410c 100644
--- a/src/date.c
+++ b/src/date.c
@@ -578,6 +578,8 @@ show_date (const char *format, struct timespec when,
timezone_t tz)
{
struct tm tm;
+ tzset ();
+
if (localtime_rz (tz, &when.tv_sec, &tm))
{
if (format == rfc_2822_format)
$ TZ="Europe/London" date-before -d 'TZ="Australia/Perth" 2016-08-15 07:00'
Mon Aug 15 07:00:00 AWST 2016
$ TZ="Europe/London" date-after -d 'TZ="Australia/Perth" 2016-08-15 07:00'
Mon Aug 15 00:00:00 BST 2016
p.s. date --debug doesn't have the issue either as it
calls localtime() within parse_datetime()
cheers,
Pádraig
