[
https://issues.apache.org/jira/browse/KYLIN-5519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713964#comment-17713964
]
ASF GitHub Bot commented on KYLIN-5519:
---------------------------------------
shaofengshi opened a new pull request, #2114:
URL: https://github.com/apache/kylin/pull/2114
## Proposed changes
Describe the big picture of your changes here to communicate to the
maintainers why we should accept this pull request. If it fixes a bug or
resolves a feature request, be sure to link to that issue.
## Branch to commit
- [ ] Branch **kylin3** for v2.x to v3.x
- [ ] Branch **kylin4** for v4.x
- [x] Branch **kylin5** for v5.x
## Types of changes
What types of changes does your code introduce to Kylin?
_Put an `x` in the boxes that apply_
- [x] Bugfix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to not work as expected)
- [ ] Documentation Update (if none of the other choices apply)
## Checklist
_Put an `x` in the boxes that apply. You can also fill these out after
creating the PR. If you're unsure about any of them, don't hesitate to ask.
We're here to help! This is simply a reminder of what we are going to look for
before merging your code._
- [x] I have created an issue on [Kylin's
jira](https://issues.apache.org/jira/browse/KYLIN), and have described the
bug/feature there in detail
- [x] Commit messages in my PR start with the related jira ID, like
"KYLIN-0000 Make Kylin project open-source"
- [x] Compiling and unit tests pass locally with my changes
- [x] I have added tests that prove my fix is effective or that my feature
works
- [x] I have added necessary documentation (if appropriate)
- [x] Any dependent changes have been merged
## Further comments
If this is a relatively large or complex change, kick off the discussion at
u...@kylin.apache.org or d...@kylin.apache.org by explaining why you chose the
solution you did and what alternatives you considered, etc...
> DateFormatTest shouldn't rely on user's timezone
> ------------------------------------------------
>
> Key: KYLIN-5519
> URL: https://issues.apache.org/jira/browse/KYLIN-5519
> Project: Kylin
> Issue Type: Improvement
> Components: Tools, Build and Test
> Affects Versions: 5.0-alpha
> Reporter: Shao Feng Shi
> Priority: Major
>
> When I run "mvn clean test", I got the following error:
>
> {code:java}
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] DateFormatTest.testStringToMillis:200 expected:<1669824000000> but
> was:<1669852800000>
> [ERROR] DateFormatTest.testStringToMillisSupplement:220
> expected:<1669824000000> but was:<1669852800000> {code}
> When look into the "DateFormatTest.testStringToMillis", it has no timezone
> specified when converting a Date time to epoch time. In the
> DateFormat.getDateFormat(), it uses the default timezone:
> {code:java}
> public static FastDateFormat getDateFormat(String datePattern) {
> FastDateFormat r = formatMap.get(datePattern);
> if (r == null) {
> r = FastDateFormat.getInstance(datePattern, TimeZone.getDefault());
> formatMap.put(datePattern, r);
> }
> return r;
> } {code}
>
> The function and test case shouldn't rely on user's default timezone. Which
> caused it may fail on another timezone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
