hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Mollitor (Jira)" <j...@apache.org>
Subject [jira] [Commented] (HIVE-22685) TestHiveSqlDateTimeFormatter Now Broken with New Year 2020
Date Tue, 14 Jan 2020 17:22:00 GMT

    [ https://issues.apache.org/jira/browse/HIVE-22685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17015230#comment-17015230
] 

David Mollitor commented on HIVE-22685:
---------------------------------------

[~klcopp] Thanks.  Love the discussion.

 I do really believe that hard-coded date is the way to go.

{quote}
testing with dates around 1970 – they aren't as likely to be actually used.
{quote}

If you would like to suggest other dates that you feel are more likely to be used, let me
know and we can update.  I think that's kind of the point though, that there is no such thing
as a good date or bad date.  However, if for example there is some sort of edge case, the
edge-case should get its own test.  One cannot introduce this edge case test if the date changes
with every test run.  For example, there is some comment about {{Thursday of the first week
in an ISO year always matches the Gregorian year.}}.  If this is something that needs testing,
I would ask that you put that test back in, after commit, with the specific date that might
cause an issue.

I also think that it's important that the expected outcome doesn't change.  For example:

{code:none}
-    checkParseTimestampIso("IY-IW-ID", "0-01-04", "iw, yyyy", "01, " + thisYearString.substring(0,
3) + "0");
-    checkParseTimestampIso("I-IW-ID", "0-01-04", "iw, yyyy", "01, " + thisYearString.substring(0,
3) + "0");
+    checkParseTimestampIso("IY-IW-ID", "0-01-04", "iw, yyyy", "01, 1970");
+    checkParseTimestampIso("I-IW-ID", "0-01-04", "iw, yyyy", "01, 1970");
     //time patterns are allowed; date patterns are not
{code}
 
Is there a unit test now testing this unit test that {{thisYearString.substring(0, 3)}} is
correct?  The cost of introducing this extra capability to make testing possible is well worth
it.

> TestHiveSqlDateTimeFormatter Now Broken with New Year 2020
> ----------------------------------------------------------
>
>                 Key: HIVE-22685
>                 URL: https://issues.apache.org/jira/browse/HIVE-22685
>             Project: Hive
>          Issue Type: Bug
>            Reporter: David Mollitor
>            Assignee: David Mollitor
>            Priority: Major
>         Attachments: HIVE-22685.1.patch, HIVE-22685.2.patch, HIVE-22685.3.patch
>
>
> Unit test is now broken.... (n)(n):(
> {code:java}
>     //Tests for these patterns would need changing every decade if done in the above
way.
>     //Thursday of the first week in an ISO year always matches the Gregorian year.
>     checkParseTimestampIso("IY-IW-ID", "0-01-04", "iw, yyyy", "01, " + thisYearString.substring(0,
3) + "0");
>     checkParseTimestampIso("I-IW-ID", "0-01-04", "iw, yyyy", "01, " + thisYearString.substring(0,
3) + "0");
> {code}
> {code}
> org.junit.ComparisonFailure: expected:<01, 20[1]0> but was:<01, 20[2]0>
> 	at org.junit.Assert.assertEquals(Assert.java:115)
> 	at org.junit.Assert.assertEquals(Assert.java:144)
> 	at org.apache.hadoop.hive.common.format.datetime.TestHiveSqlDateTimeFormatter.checkParseTimestampIso(TestHiveSqlDateTimeFormatter.java:313)
> 	at org.apache.hadoop.hive.common.format.datetime.TestHiveSqlDateTimeFormatter.testParseTimestamp(TestHiveSqlDateTimeFormatter.java:287)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message