Mailing-List: contact dev-help@tajo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@tajo.apache.org
Received-SPF: pass (nike.apache.org: domain of eminency@gmail.com designates
 209.85.214.171 as permitted sender)
MIME-Version: 1.0
References: 
 <CAGLKYAk1=3X1GvjWxJWWFOOfHC=L28QvQd0rKq3hoEH8qJv2Lw@mail.gmail.com>
From: Jong-young Park <eminency@gmail.com>
Date: Mon, 17 Nov 2014 07:28:47 +0000
Message-ID: 
 <CAGvFKvS2FYH01-8ZGd7ag6SKf3J3QkTRDW=9cFnSeXvD-SGpRA@mail.gmail.com>
Subject: Re: Timezone issues
To: dev@tajo.apache.org
Content-Type: multipart/alternative; boundary=001a113ad19cf55ee6050808ed1a

--001a113ad19cf55ee6050808ed1a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

As I know, there are remained timezone issues currently and somethings are
known.

Including theses,

https://issues.apache.org/jira/browse/TAJO-1063
https://issues.apache.org/jira/browse/TAJO-1064

(One is assigned to me, but never mind. I'm not touching now)

As I investigated, timezone problems are connected one another. Thus, if it
is modified simply, other problems happens and test cases are failed.
So I have delayed the issue for weeks because of other tasks.

Anyway, I think no one is taking a look at them and you can handle.

Regards,
Jongyoung.

On Mon Nov 17 2014 at =EC=98=A4=ED=9B=84 12:47:54 Jaewoong Jung <jungjw@gma=
il.com> wrote:

> I found two test cases are failing on my machines due to timezone
> issues. (Of course, on unmodified latest clients)
>
> 1. TestIntervalDatum#testOperation - the one testing DateDatum +
> TimeDatume (line #91)
>
> On my machines, the result value is 2001-09-29 03:00:00, not
> 2001-09-28 03:00:00. The reason it fails is, I assume, in
> DateDatum#plus, it converts tm2 to a local time before adding it to
> tm1, where I see two issues.
>
> (1) Why does it bother to change it to a local time before adding and
> change it back to UTC after that? I don't see any points in doing so.
>
> (2) Supposing there are some reasons behind it, why does it convert an
> "interval" (in this case, tm2) to a local time? Intervals don't have
> timezones, so it doesn't make sense at all. And, in my case, since my
> machines are set to PST, which is UTC -8:00, it tries to subtract 8
> hours from 3 hours, and I'm thinking it's causing some kind of
> underflow error. As a proof, it works just fine if I change DateDatum,
> line 129 from DateTimeUtil.toUserTimezone(tm2) to
> DateTimeUtil.toUserTimezone(tm1). (tm1 is a TimeMeta of the DateDatum
> to add an interval to, and tm2 is the interval's TimeMeta.)
>
> 2. TestTimestampDatum#testTimestampConstructor, line 163
>
> It compares a Calendar instance, which returns local year, month, date
> values, with a TimestampDatum instance, which returns UTC year, month,
> date values except for toString and asChars values. As a result, it
> passes on my machine in the morning, but fails in the evening.
>
> ---
>
> Both tests run fine if I change the timezone to London, which is
> another reason I strongly believe these are timezone issues.
>
> Is anyone working on these issues? If not, I can fix them myself.
>
> Cheers,
> Jaewoong
>

--001a113ad19cf55ee6050808ed1a--