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 오후 12:47:54 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 >
