Yuck!

Can confirm the same with an Enterprise Source Type with the Esri ArcGIS Feature Service Reader

​@braggken - have you confirmed that you can’t write the epoch time using the newer writer and conversion is required?

I’ve not managed to get the newer writer working at all yet...

Thanks for confirming ​@ebygomm - can you tell me your version of FME please?
No I can’t write epoch time with the new writer, at least not an existing AGOL feature layer.  The other hitch I noticed is that where there was already a GlobalID field in the layer it seems we now have to send a guid along whereas before that was not needed.

We are going to have to migrate our Enteprise readers/writers also which will be a much bigger job.   

Using the same package (Esri ArcGIS Connector 3.11.1) I've tested connecting from

• FME 2024.1.0.0 Build 24612
• FME 2025.1.0.1 Build 25609 

Further to the above, I’ve now managed to update an Enterprise feature service using the Esri ArcGIS Feature Service writer - I get a permissions issue if i try to use token authentication but it worked with Oauth authentication. 

I can update a date field sending either milliseconds since epoch or an FME date time (attribute type needs to be datetime) to the writer

Esri data types for Feature Services are always such a pain… Especially the datetime datatypes. 

To convert UNIX millisecond epoch time to YYYYMMDD format, you need to use the AttributeManager’s Arithmetic Editor to first convert the UNIX milliseconds to seconds (e.g., @Value(ATTRIBUTENAME)/1000). Then, use the DateTimeConverter transformer to format UNIX seconds into YYYYMMDD. Depending on your workflow, you could create a dynamic workspace that only rectifies the date values for Feature Services.

Additionally, there’s also a quirk with Esri Feature Services where you cannot write the value 19700101000000 and Esri converting Date Time value to local time zones (Note: I am not sure if this behavior is still present with Esri Feature Services). My memory is a bit hazy, but you can find the thread here:

Yes thanks ​@geospatialize  as I mentioned in the inital post,  “Obviously this can be worked around ..“  but its good to have posted the details.
But the issue is the way datetimes are read by the new reader has changed. We have over 100 workspaces that read and write AGOL and Portal many of which manipulate datetimes within.  Also rather annoyingly, the new datetime format cannot be handled by DateTimeConverter so as you pointed out, the work-around involves an additional step for every datetime attribute being handled to convert from milliseconds to seconds. 

It certainly gives no indication in the article “Working with Esri ArcGIS Feature Services in FME” that there is a fundamental change in the data being returned when using the new reader v the old. And it concerns me that there might be other similar discrepancies. 

About the date using the new Writer, I have also been able to insert dates in FME format, but it keeps throwing errors when I use dates in milliseconds (even though the value is exactly the same as the ArcGIS feature Reader returns).

I have made sure to set the type as “datetime” with An AttributeManager. Did you do anything else to make it work with milliseconds?

Hi folks,

I've submitted a ticket for this behavior (FMEENGINE-87880).

The current workaround for the ArcGIS Feature Service Writer to accept UNIX milliseconds (if Data type is String) is to set the Attribute Definition as Manual and specify the Attribute with the Date value in an arithmetic editor within the Writer's User Attributes.

I apologize for this inconvenience. Thank you for your understanding.

So i hadn’t tried to insert a new feature with a date in milliseconds, just update an existing and that worked with no other changes other than setting a new value in the AttributeCreator (I thought it wasn’t updated for a while until i realised that although milliseconds are returned, only whole seconds seem to be accepted, i.e. a value of 1757434408001 ends up as 1757434408000)

I don’t even want to look into how this impacts dynamic workflows….