[
https://issues.apache.org/jira/browse/PIG-4267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197426#comment-14197426
]
Rohini Palaniswamy edited comment on PIG-4267 at 11/5/14 3:11 AM:
------------------------------------------------------------------
bq. As far as test cases go, I can't. The issue is that it depends on whether
it's EDT or EST when you run the test.
If code behaves based on whether it is EDT or EST now then I believe it is
wrong. It should look at the time in question and give the correct time zone
offset for that time. OOZIE-1573 is a similar issue. Given a UTC time/java
millis, it should always return the offset on that time.
For Eg:
Given http://www.timeanddate.com/time/change/usa/new-york
Sunday, March 9, 2014, 2:00:00 AM clocks were turned forward 1 hour to
Sunday, March 9, 2014, 3:00:00 AM local daylight time instead
Sunday, November 2, 2014, 2:00:00 AM clocks were turned backward 1 hour to
Sunday, November 2, 2014, 1:00:00 AM local standard time instead
I would expect the following outputs irrespective of whether it is EDT or EST
at the time of running it.
GMT -> America NewYork
March 9, 2014 5:00:00 AM -> March 9, 2014 00:00:00 AM EST UTC-5 hours
March 9, 2014 6:00:00 AM -> March 9, 2014 01:00:00 AM EST UTC-5 hours
March 9, 2014 7:00:00 AM -> March 9, 2014 03:00:00 AM EDT UTC-4 hours
Nov 2, 2014 4:00:00 AM -> Nov 2, 2014 00:00:00 AM EDT UTC-4 hours
Nov 2, 2014 5:00:00 AM -> Nov 2, 2014 01:00:00 AM EDT UTC-4 hours
Nov 2, 2014 6:00:00 AM -> Nov 2, 2014 01:00:00 AM EST UTC-5 hours
Nov 2, 2014 7:00:00 AM -> Nov 2, 2014 02:00:00 AM EDT UTC-5 hours
Used GMT instead of java time in millis (since 1970) in above example for easy
reading. Used
http://www.timeanddate.com/worldclock/converted.html?iso=20141102T05&p1=136&p2=179
for getting the above values.
was (Author: rohini):
bq. As far as test cases go, I can't. The issue is that it depends on whether
it's EDT or EST when you run the test.
If code behaves based on whether it is EDT or EST now then I believe it is
wrong. It should look at the time in question and give the correct time zone
offset for that time. OOZIE-1573 is a similar issue. Given a UTC time/java
millis, it should always return the offset on that time.
For Eg:
Given http://www.timeanddate.com/time/change/usa/new-york
Sunday, March 9, 2014, 2:00:00 AM clocks were turned forward 1 hour to
Sunday, March 9, 2014, 3:00:00 AM local daylight time instead
Sunday, November 2, 2014, 2:00:00 AM clocks were turned backward 1 hour to
Sunday, November 2, 2014, 1:00:00 AM local standard time instead
I would expect the following output
GMT -> America NewYork
March 9, 2014 5:00:00 AM -> March 9, 2014 00:00:00 AM EST UTC-5 hours
March 9, 2014 6:00:00 AM -> March 9, 2014 01:00:00 AM EST UTC-5 hours
March 9, 2014 7:00:00 AM -> March 9, 2014 03:00:00 AM EDT UTC-4 hours
Nov 2, 2014 4:00:00 AM -> Nov 2, 2014 00:00:00 AM EDT UTC-4 hours
Nov 2, 2014 5:00:00 AM -> Nov 2, 2014 01:00:00 AM EDT UTC-4 hours
Nov 2, 2014 6:00:00 AM -> Nov 2, 2014 01:00:00 AM EST UTC-5 hours
Nov 2, 2014 7:00:00 AM -> Nov 2, 2014 02:00:00 AM EDT UTC-5 hours
Used GMT instead of java time in millis (since 1970) in above example for easy
reading.
> ToDate has incorrect timezone offsets
> -------------------------------------
>
> Key: PIG-4267
> URL: https://issues.apache.org/jira/browse/PIG-4267
> Project: Pig
> Issue Type: Bug
> Affects Versions: 0.12.0, 0.13.1
> Environment: java version 1.7.0_72
> Reporter: Brian Johnson
> Assignee: Brian Johnson
> Attachments: patch
>
>
> If you set the timezone to 'America/New_York'
> Pig will return "2012-03-30 -05:00" for ToDate(1333166400000) instead of the
> correct "2012-03-31 -04:00"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
