[
https://issues.apache.org/jira/browse/NIFI-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16177986#comment-16177986
]
ASF subversion and git services commented on NIFI-2829:
-------------------------------------------------------
Commit c6f4421c8e59c896ed9887ced256a73b920f4ccb in nifi's branch
refs/heads/master from [~ijokarumawak]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=c6f4421 ]
NIFI-2829: Fixed PutSQL time unit test.
The unit test for DATE type used GMT timezone, that causes an assertion error
in timezones such as EST (-5).
We need to use local timezone instead of GMT, as Derby and PutSQL uses local
timezone.
The unit test failed before as follows:
- Unit test code, passed: '2002-02-02 GMT'
- PutSQL code convertedi it to local: '2002-02-01 EST', and stored as
'2002-02-01' in Derby database without timezone info
- Unit test code SELECT the inserted value, passed a GMT calender, then got
epoch timestamp, which was '2002-01-31'
Support negative long value for timezones ahead of UTC.
- For timezones such as '+0800', it's possible that a local time e.g.
'02:03:04' can be a negative epoch value. This commit changes LONG_PATTERN so
that it can accept nevative values.
- Changed time values in unit tests to verify negative epoch values, and avoid
using the same digits among different time unit for better readability.
This closes #2082
> PutSQL assumes all Date and Time values are provided in Epoch
> -------------------------------------------------------------
>
> Key: NIFI-2829
> URL: https://issues.apache.org/jira/browse/NIFI-2829
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Reporter: Paul Gibeault
> Assignee: Peter Wicks
> Fix For: 1.4.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> This bug is the same as NIFI-2576 only extended to data types DATE and TIME.
> https://issues.apache.org/jira/browse/NIFI-2576
> When PutSQL sees a DATE or TIME data type it assumes that it's being provided
> as a Long in Epoch format.
> This doesn't make much sense since the Query Database tools that return Avro
> return DATES and TIME values as strings; and thus following the
> Avro->JSON->JSON To SQL Route leads to DATE and TIME fields as being strings.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)