tajo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaewoong Jung <jun...@gmail.com>
Subject Re: Timezone issues
Date Tue, 18 Nov 2014 07:53:18 GMT
Ok, I created JIRA issues for the problems I asked.

https://issues.apache.org/jira/browse/TAJO-1191
https://issues.apache.org/jira/browse/TAJO-1192

Day Myung, please feel free to pick up any issues you'd like to
including other ones that Jong-young and Hyunsik mentioned. I'll
assign issues to myself before beginning to work on them.

Cheers,
Jaewoong

On Mon, Nov 17, 2014 at 9:29 AM, CharSyam <charsyam@gmail.com> wrote:
> Yes, I also fix one testcase because of timezone.
>
> If I can, I can fix this issues :)
>
> 2014-11-17 19:44 GMT+09:00 Hyunsik Choi <hyunsik.choi@gmail.com>:
>
>> Hi Jaewoong,
>>
>> Thank you for this bug reporting and nice finding. They are all bugs.
>> As you mentioned, interval does not have timezone. As far as I know,
>> nobody works the issues now and there are no Jira issues for them. You
>> can feel free to start the issue.
>>
>> Before you starts the issue, I'd like to give a brief background about
>> timezone. You may already know it. Tajo translates the timezone of
>> input data when Tajo reads the data. Then, Tajo internally processes
>> all data with UTC+0 due to simplicity of processing. When a user
>> retrieves the query result, the result is translated to user's
>> timezone.
>>
>> FYI, I share known problems with you. I've just created the known
>> issues that I found. Actually, I'm also working on TAJO-1186.
>>
>> https://issues.apache.org/jira/browse/TAJO-1185
>> https://issues.apache.org/jira/browse/TAJO-1186
>> https://issues.apache.org/jira/browse/TAJO-1187
>>
>> Best regards,
>> Hyunsik
>>
>> On Sun, Nov 16, 2014 at 7:47 PM, Jaewoong Jung <jungjw@gmail.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
>>

Mime
View raw message