palak-9202 commented on code in PR #13428:
URL: https://github.com/apache/arrow/pull/13428#discussion_r919760316
##########
cpp/src/gandiva/gdv_function_stubs_test.cc:
##########
@@ -993,4 +993,61 @@ TEST(TestGdvFnStubs, TestTranslate) {
EXPECT_EQ(expected, std::string(result, out_len));
}
+TEST(TestGdvFnStubs, TestToUtcTimezone) {
+ gandiva::ExecutionContext context;
+ auto context_ptr = reinterpret_cast<int64_t>(&context);
+ gdv_int32 len_ist = static_cast<gdv_int32>(strlen("Asia/Kolkata"));
+ gdv_int32 len_pst = static_cast<gdv_int32>(strlen("America/Los_Angeles"));
+
+ //2012-02-28 15:30:00 Asia/Kolkata
+ gdv_timestamp ts = 55800000;
+ gdv_timestamp ts2 = to_utc_timezone_timestamp(context_ptr, ts,
+ "Asia/Kolkata", len_ist);
+ EXPECT_EQ(36000000, ts2);
+
+ //1970-01-01 5:00:00 Asia/Kolkata
+ ts = 18000000;
Review Comment:
Hey, actually since the function takes in the timestamp separate from the
time zone, the time stamp is not adjusted for zone offset (this is done to
match the hive function implementation). so what the function receives is a
timestamp that should be interpreted as the time in the zone given as second
parameter. That's why the function subtracts the offset to get UTC time even
though the actual equivalent timestamp is the same, just the representation of
the date+time is different.
So my comments are misleading- the input is just a date + time whose
timestamp will be casted based on 0 offset. See the projector test about this.
I will remove the time zone names from the comments.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
