[
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)
