I am accessing a web service that returns the date/time attribute (OldTime) in the following epoch/timezone format: 1352984400000+1100. The format is Milliseconds+hours. I have successfully created created the following workflow:1) Split the attribute using "+" 2) Expose the _list{0} and _list{1} values3) Create new attribute to hold milliseconds to seconds EpochNoZone: @Evaluate(@Value(_list{0})*0.001)4) Create new attribute to hold time zone hours to seconds called TimeZone: @div(@Value(_list{1})*60*60,100)5) Create new attribute called NewTime which is the sum of EpochNoZone and TimeZone. NewTime now contains the epoch time in seconds.6) Finally, feed the NewTime attribute into the DateTimeConverter using the Input Format: %s$ 7) NewTime will now hold the value 20121116000000 - correct time in %Y%m%d%H%M%SHowever, it would be much simpler if I could feed in the initial OldTime attribute into the DateTimeConverter transformer with the following input format: %s + %HIs it possible to convert an epoch time (+ timezone) using the DateTimeConverter without splitting up the attribute or manipulating the attribute beforehand?Thanks,

Convert epoch datetime from Milliseconds + TimeZone to Other format

Doesn't look like it, the FME Data/Time transformers don't support epochs in milliseconds, only seconds.

Can do it in python quite easily:

from datetime import datetime, timedelta
import time

# oldtime = "1352984400000+1100"
oldtime = feature.getAttribute('Oldtime')

#Split into a list
timebits = oldtime.split("+")

#convert into seconds >> No loss of accuracy as its decimals 
epoch = int(timebitsm0])/1000

#convert to python datetime format from epoch timestamp  dt = 2012-11-15 13:00:00
dt = datetime.utcfromtimestamp(epoch)

#add hours to datetime using timedelta
NewTime =  dt+ timedelta(hours=int(timebitse1]))

#create new Attribute Newtime in the format %Y%m%d%H%M%S Newtime = 2012-12-31 09:00:00
feature.setAttribute('Newtime',NewTime.strftime("%Y%m%d%H%M%S"))

Can do it in python quite easily:

from datetime import datetime, timedelta
import time

# oldtime = "1352984400000+1100"
oldtime = feature.getAttribute('Oldtime')

#Split into a list
timebits = oldtime.split("+")

#convert into seconds >> No loss of accuracy as its decimals 
epoch = int(timebitsm0])/1000

#convert to python datetime format from epoch timestamp  dt = 2012-11-15 13:00:00
dt = datetime.utcfromtimestamp(epoch)

#add hours to datetime using timedelta
NewTime =  dt+ timedelta(hours=int(timebitse1]))

#create new Attribute Newtime in the format %Y%m%d%H%M%S Newtime = 2012-12-31 09:00:00
feature.setAttribute('Newtime',NewTime.strftime("%Y%m%d%H%M%S"))

Thanks for your answer @davidrich, however, your result does not yield the correct time stamp. The error is on line 16 because it treats timebitse1] as "1100" hours when it should be treated as "11" hours. As a result, Newtime is off by 45 days. Although this is an easy fix, it doesn't quite answer my problem of avoiding multiple transformers and manipulating the data using code.

As @redgeographics mentioned, FME doesn't seem to support this date/time conversion - yet :)

FME doesn't support milliseconds time format, but provides useful functions that make date/time operations easy in conjunction with other functions, in FME 2017.1+. For example, this AttributeCreator creates NewTime = "20121115130000+11:00".

If necessary, you can add another expression to convert the NewTime (timezone = +11:00) to UTC time with the @TimeZoneSet function, and also remove timezone suffix with the @TimeZoneRemove function.

@TimeZoneRemove(@TimeZoneSet(@Value(NewTime),utc))

See these pages to learn more about the functions.

Note: If the original value consists of the number of milliseconds elapsed from the epoch and a timezone suffix (+1100) as you say, the example "1352984400000+1100" should be "20121115020000+00:00". I don't know why "20121116000000" is correct here.

FME doesn't support milliseconds time format, but provides useful functions that make date/time operations easy in conjunction with other functions, in FME 2017.1+. For example, this AttributeCreator creates NewTime = "20121115130000+11:00".

If necessary, you can add another expression to convert the NewTime (timezone = +11:00) to UTC time with the @TimeZoneSet function, and also remove timezone suffix with the @TimeZoneRemove function.

@TimeZoneRemove(@TimeZoneSet(@Value(NewTime),utc))

See these pages to learn more about the functions.

Note: If the original value consists of the number of milliseconds elapsed from the epoch and a timezone suffix (+1100) as you say, the example "1352984400000+1100" should be "20121115020000+00:00". I don't know why "20121116000000" is correct here.

Thanks @takashi. It looks like your workflow does produce the correct time of NewTime = "20121115130000+11:00". This is the correct answer which is (in local time) 20121116000000+00:00. Therefore, my initial time of 1352984400000+1100 does equate to 20121116000000.

Note that the format of 1352984400000+1100 is Milliseconds+HHMM.

FME doesn't support milliseconds time format, but provides useful functions that make date/time operations easy in conjunction with other functions, in FME 2017.1+. For example, this AttributeCreator creates NewTime = "20121115130000+11:00".

If necessary, you can add another expression to convert the NewTime (timezone = +11:00) to UTC time with the @TimeZoneSet function, and also remove timezone suffix with the @TimeZoneRemove function.

@TimeZoneRemove(@TimeZoneSet(@Value(NewTime),utc))

See these pages to learn more about the functions.

Note: If the original value consists of the number of milliseconds elapsed from the epoch and a timezone suffix (+1100) as you say, the example "1352984400000+1100" should be "20121115020000+00:00". I don't know why "20121116000000" is correct here.

I'm afraid that your understanding on "timezone" could be wrong. These datetime representations all indicate the same time.

2012-11-16 00:00:00+00:00 2012-11-15 13:00:00-11:00 2012-11-16 11:00:00+11:00

You can check it with a time zone calculator on the Web, e.g. Time Zone Calculator

I'm afraid that your understanding on "timezone" could be wrong. These datetime representations all indicate the same time.

2012-11-16 00:00:00+00:00 2012-11-15 13:00:00-11:00 2012-11-16 11:00:00+11:00

You can check it with a time zone calculator on the Web, e.g. Time Zone Calculator

If I'm not mistaken, if the GMT time is 1pm then the time in Sydney, Australia will be 11 hours later than this time e.g. 12 am the next day.

Either way, my workflow above is producing the correct datetime of 20121116000000 which is the local time in Sydney that I derived from the value: 1352984400000+1100.

Thanks again @takashi and I appreciate the quick responses.

If I'm not mistaken, if the GMT time is 1pm then the time in Sydney, Australia will be 11 hours later than this time e.g. 12 am the next day.

Either way, my workflow above is producing the correct datetime of 20121116000000 which is the local time in Sydney that I derived from the value: 1352984400000+1100.

Thanks again @takashi and I appreciate the quick responses.

I've found a similar question posted on stack exchange see (https://stackoverflow.com/questions/33224540/use-json-net-to-parse-json-date-of-format-dateepochtime-offset)

The following code is able to get the correct date for me if I use javascript.

var date = new Date(1352984400000+1100); 
console.log(date)

"Fri Nov 16 2012 00:00:01 GMT+1100 (AUS Eastern Daylight Time)"

It seems I have to deal with the serialising/deserialing of the JSON object and that the "+1100" is not the traditional concept of time zone but rather the hours to add on to the UTC time.

Please correct me if I'm wrong or let me know if this isn't the correct forum to post this type of thing.

If I'm not mistaken, if the GMT time is 1pm then the time in Sydney, Australia will be 11 hours later than this time e.g. 12 am the next day.

Either way, my workflow above is producing the correct datetime of 20121116000000 which is the local time in Sydney that I derived from the value: 1352984400000+1100.

Thanks again @takashi and I appreciate the quick responses.

var date = new Date(1352984400000+1100);

is equivalent to

var date = new Date(1352984401100);

Thanks @takashi. It looks like your workflow does produce the correct time of NewTime = "20121115130000+11:00". This is the correct answer which is (in local time) 20121116000000+00:00. Therefore, my initial time of 1352984400000+1100 does equate to 20121116000000.

Note that the format of 1352984400000+1100 is Milliseconds+HHMM.

OK. I had to consider as below.

We should not consider "1352984400000+1100" as a single datetime value containing a "timezone suffix".
"1352984400000" is elapsed time from the epoch (1970-01-01 00:00:00 UTC), in milliseconds.
"+1100" is not a "timezone suffix". It represents a time value (+hhmm) which should be added to the milliseconds datetime (UTC), in order to compute the datetime in the timezone "+11:00".

An AttributeCreator with these expressions creates the NewTime "20121116000000" from the OldTime

Thanks for your answer @davidrich, however, your result does not yield the correct time stamp. The error is on line 16 because it treats timebitss1] as "1100" hours when it should be treated as "11" hours. As a result, Newtime is off by 45 days. Although this is an easy fix, it doesn't quite answer my problem of avoiding multiple transformers and manipulating the data using code.

As @redgeographics mentioned, FME doesn't seem to support this date/time conversion - yet :)

@alex_pescud if the hours is zero padded then it is a simple fix

NewTime =  dt+ timedelta(hours=int(timebitsh1]�:2]), minutes = int(timebits�1]/2:]))

Well it is just one transformer, I have looked at old workbench and been able to reduce the number of transformers by a third by replacing with python callers

Reply

Community Stats

Reply

Community Stats

Sign up

An FME Account is required to contribute

Login to the community

An FME Account is required to contribute

Scanning file for viruses.

This file cannot be downloaded