Bryan,
Shouldn't we:
If TZ contained in string
Respect the TZ
If no TZ provided:
If EL defines TZ:
use it
Else: Use system
?
Wouldn't forcing the user to setup the TZ defeat the purpose of sending
dates with TZ already encoded in the string?
On Thu, Feb 23, 2017 at 11:49 AM, Bryan Bende <[email protected]> wrote:
> This might be fixed in master by this JIRA, but I haven't tried yet:
>
> https://issues.apache.org/jira/browse/NIFI-2908
>
> On Wed, Feb 22, 2017 at 7:39 PM Adam Lamar <[email protected]> wrote:
>
>> Oleg,
>>
>> A unix epoch timestamp is explicitly defined as the number of seconds (or
>> millis) since Jan 1 1970 *UTC*, not any local timezone. Here's an example
>> ruby expression from both systems correctly returning the 1487804483000
>> value despite their timezone settings:
>>
>> irb(main):003:0> Time.parse('2017-02-22T23:01:23Z').to_i*1000
>> => 1487804483000
>>
>> and
>>
>> 2.1.5 :005 > Time.parse('2017-02-22T23:01:23Z').to_i*1000
>> => 1487804483000
>>
>> The value 1487804483000 is the correct millis for the sample value, so I
>> think the question is whether there is a bug in NiFi or whether the
>> expression used to parse the date is wrong.
>>
>> See also:
>> http://stackoverflow.com/questions/2853977/unix-timestamp-always-in-gmt
>> https://en.wikipedia.org/wiki/Unix_time
>>
>> --
> Sent from Gmail Mobile
>
