Adam,
Credit goest to JWitt but have you tried:
${zulu:toDate("yyyy-MM-dd'T'HH:mm:ssXXX", "UTC"):toNumber()}
?
It is counter intuitive (as you must specify the UTC)
The following template should illustrate
https://gist.github.com/trixpan/f9aaf5081500a6afbcd0e237d9c9c864
On Thu, Feb 23, 2017 at 11:59 AM, Andre <[email protected]> wrote:
> 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
>>
>
>
