Jyotman Singh

Hi Jeff, apologies for the late reply. This will take significant effort as the tests will require a complete rewrite due to the return type of the method changing and will also need to find a way to test the setSqlValue() method since it'll contain some logic too because of the above suggested approach. I'll try to find some time to do this but can't promise a timeline right now. Will keep you updated though if/when I start working on this. Thanks for the help so far! Also fine if someone else wants...

Hi Jeff, Yes, I agree! I'm also not happy with the additional steps required in setSqlValue() but I can't return Timestamp from typeCast because it doesn't retain the expected dataset zone. I need to return the correct zone along with the Timestamp so that the statement.setTimestamp can receive the correct zone along with the Timestamp in the form of the Calendar instance. So I deemed ZonedDateTime as the correct choice which retains the datatime as well as the desired zone. I thought about returning...

Hi Jeff, Yes, I agree! I'm also not happy with the additional steps required in setSqlValue() but I can't return Timestamp from typeCast because it doesn't retain the expected dataset zone. I need to return the correct zone along with the Timestamp so that the statement.setTimestamp can receive the correct zone along with the Timestamp in the form of the Calendar instance. So I deemed ZonedDateTime as the correct choice which retains the datatime as well as the desired zone. I thought about returning...

Hi Jeff, Yes, I agree! I'm also not happy with the additional steps required in setSqlValue() but I can't return Timestamp from typeCast because it doesn't retain the expected dataset zone. I need to return the correct zone along with the Timestamp so that the setTimestamp can received the correct zone along with the Timestamp in the form of the Calendar instance. So I deemed ZonedDateTime as the correct choice which retains the datatime as well as the desired zone. I thought about returning a Calendar...

To make it more clear, I've added another test that would fail on any system not running on UTC - public void testWithTimezone_RetainTimezone() throws Exception { String ts = "2013-01-27 01:22:41.900 +0000"; String expected = "2013-01-27 01:22:41.9"; String received = THIS_TYPE.typeCast(ts).toString(); assertEquals(expected, received); } I've also attached a debug screenshot of my system running on UTC+8 (Singapore) timezone.

Hi Jeff, thanks for your prompt reply. This is difficult to test typeCast as the problem seems to be in the return type of the function itself. The current return type java.sql.Timestamp uses the machine's default timezone which leads to neglecting the timezone provided in the DBUnit dataset. To fix this would involve returning different type from typeCast that can respect the timezone provided in the dataset. But still to prove my point, this test would always fail. Same UTC value but depends on...

Hi Jeff, thanks for your prompt reply. This is difficult to test typeCast as the problem seems to be in the return type of the function itself. The current return type java.sql.Timestamp uses the machine's default timezone which leads to neglecting the timezone provided in the DBUnit dataset. To fix this would involve returning different type from typeCast that can respect the timezone provided in the dataset. But still to prove my point, currently this test would fail. Same UTC value but assume...

Hi Jeff, thanks for your prompt reply. This is difficult to test typeCast as the problem seems to be in the return type of the function itself. The current return type java.sql.Timestamp uses the machine's default timezone which leads to neglecting the timezone provided in the DBUnit dataset. To fix this would involve returning different type from typeCast that can respect the timezone provided in the dataset. But still to prove my point, currently this test would fail - public void test() throws...