Hi Hyunsik. I also agree. It is just workaround for this problem. and we need a essential solution that supporting timezone well.
but everyday, I encounter this bug. so, I think workaround is need this time. 2014-11-19 16:29 GMT+09:00 Hyunsik Choi <[email protected]>: > Hi CharSyam, > > Thank you for your contribution. In my opinion, you patch seems to be > a workaround code for the unit test. Probably, we need a essential > solution. > > Warm regards, > Hyunsik > > On Tue, Nov 18, 2014 at 12:52 AM, CharSyam <[email protected]> wrote: > > Hi, Jaewoong :) > > I already pull request it in https://github.com/apache/tajo/pull/249 > > I tried to compile tajo at 2:00AM. > > I found this bug. > > > > 2014-11-18 16:53 GMT+09:00 Jaewoong Jung <[email protected]>: > > > >> 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 <[email protected]> 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 <[email protected]>: > >> > > >> >> 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 <[email protected]> > >> 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 > >> >> > >> >
