If I recall correctly, epoch times should always be free from time zone, always representing seconds/milliseconds since epoch at UTC
So for the original timestamp 2017-02-22T23:01:23Z = 1487804483000 = 2017-02-22T16:01:23+0700 While 2017-02-23T06:01:23Z. =1487829683000 != 2017-02-22T23:01:23Z There seems to be a 7 hours negative from UTC, suggesting the calculation occurred on local time? Seems like a bug to me On Thu, Feb 23, 2017 at 11:08 AM, Oleg Zhurakousky < [email protected]> wrote: > Adam, > > I think if my math is correct, what you seeing is correct since > 22T23:01:23 + 7 = 23T06:01:23 > > Am i missing something? > Cheers > Oleg > > On Feb 22, 2017, at 6:42 PM, Adam Lamar <[email protected]> wrote: > > Hi, > > I recently noticed some issues with time parsing in the expression > language. > > On my Linux server configured with UTC time, using UpdateAttribute to > convert a timestamp value to millis works as expected. > > Attribute name: timestamp > Sample value: 2017-02-22T23:01:23Z > > UpdateAttribute is configured with the following property: > > name: timestamp_millis > value: ${timestamp:toDate("yyyy-MM-dd'T'HH:mm:ss'Z'"):toNumber()} > > For the above sample value, I get 1487804483000 as timestamp_millis. > > epochconverter.com converts timestamp_millis back to the same timestamp > provided above. > > On my local OSX dev system with a UTC offset of -07:00, the same timestamp > input yields timestamp_millis as 1487829683000, or the equivalent of > 2017-02-23T06:01:23Z. > > Is my expression language incorrect, or is something else wrong? > > Adam > > >
