How can I convert 10 digit epoch time to correct date/time?

[JeffreyWilkerson]

We have a GeoEvent input reading a JSON web service for bus locations. The time field is called 'timestamp' and its value is an epoch time stamp such as '1589215201' (converts to the right date/time on https://www.epochconverter.com/).

The input connector definition defines this as a date with nothing specified as the date format. There is a field mapper to move this into a feature class output as the input schema/geoevent definition is not flat.  The output connector updates a feature class on our Portal system and the timestamp field becomes the 'eventtime' field but is still considered a date type.

When this runs everything works fine with no errors in the GeoEvent logs, but the date for all records is '1/19/1970 9:27:03 AM'.  The only difference that I can see from the Esri documentation is that our 'epoch' time format has only 10 characters, where the Esri examples show 13. But our numbers still validate at the EpochConverter web site.

Is GeoEvent server not able to handle this as a date?  Or is there a way to read it in as a string, or a long, and then convert it to the correct date?

[Egge-Jan_Pollé · Accepted solution]

Hi Jeffrey Wilkerson,

Did you see this blogpost: https://community.esri.com/community/gis/enterprise-gis/geoevent/blog/2019/03/14/what-time-is-it-wel... ?

It looks like GeoEvent likes its epoch time in milliseconds, so maybe you should multiply your time stamps by a thousand: 1589215201 * 1000 gives 1589215201000‬. Hey, this is 13 characters instead of 10... 🙂

Does this solution work for you?

BR,

Egge-Jan

[JeffreyWilkerson]

Thank you Egge-Jan.  I've seen that blogpost and it's a good one that I keep going back to.  It doesn't directly answer my question though as it says GeoEvent is expecting UTC format, just as the Esri documentation is.  I think it's expecting a 13 character UTC format only though.  With that, your solution looks like it would work.  I will give it a shot.  I would still like to know if it is indeed the case that GeoEvent server can't read a 10 character UTC format though.  If you enter 1589215201 into the EpochConverter web site it gives you the same date/time as 1589215201000, the smaller number is just in seconds and the latter in miliseconds.  

Thanks for your suggestion. 

[Egge-Jan_Pollé]

I think it will solve your issue. Just let us know the results of your test. And: don't forget to mark the question as being answered correctly (if this is indeed the solution...)

BR,

Egge-Jan

[JeffreyWilkerson]

Thank you Egge-Jan, that solution works.  I created a field calculator processesor which feeds into a field mapper processesor and that is pulled into the output feature web service.  The input connector has the field as a long, the field calculator multiplies this by 1000 and sends it to a new date field.  Then the final connector has a date field to accept the mapped field. 

Jeff