Skip to main content
  • EN

I have a hosted feature service in Portal for ArcGIS 10.6.1.

I can read the feature service with FME 2019.0.0.1 Build 19246 - win32. However the date fields are read with a value that is 2 hours earlier.

In Portal for ArcGIS, in the hosted feature data tab I see the date that we entered into the service via the Survey123 app: 5/27/2019, 12:00AM

When I read the same record with FME the value is 20190526220000:

Both the Portal for ArcGIS Server and the FME Server are set to UTC +1 with daylight saving time. The time for both servers is the same.

The hosted feature service was made via Survey123 - thus the data sits in the Portal. The field above is filled in with the Survey123 form but I also see that the editor tracking fields are affected.

We use FME to make a report of the Survey123 collected records so it is important that the dates are correct. I also see the issue if I read the data in FME Desktop.

Has anyone experienced this sort of issue before?

Thanks,

Annette

 

Sounds familiar. I think the issue is AGS saving the datestamp (2019-05-27) as a datetimestamp (adding 12:00:00 AM).

The API returns datetimestamp in epoch in miliseconds: 1558915200000 which equals to 2018-04-11 12:00:00 AM GMT.

Now I'm not sure anymore what did it, but something is correcting your datetimestamp the wrong way around when fixing it from GMT to GMT+02:00.

What date do you get from Portal when you request the record via the rest API?

I tried to reproduce the problem but it is now working like a charm :-| (in both 2016 and 2019) so I'm afraid I can't help at the moment. But I have seen a similar issue.

Sounds familiar. I think the issue is AGS saving the datestamp (2019-05-27) as a datetimestamp (adding 12:00:00 AM).

The API returns datetimestamp in epoch in miliseconds: 1558915200000 which equals to 2018-04-11 12:00:00 AM GMT.

Now I'm not sure anymore what did it, but something is correcting your datetimestamp the wrong way around when fixing it from GMT to GMT+02:00.

What date do you get from Portal when you request the record via the rest API?

I tried to reproduce the problem but it is now working like a charm :-| (in both 2016 and 2019) so I'm afraid I can't help at the moment. But I have seen a similar issue.

Thanks Niels for looking into this. Much appreciated. The API is returning 1558908000000 or Sunday, May 26, 2019 10:00:00 PM GMT. See screenshot below.

As a workaround I've added 12 hours to the date as we just want to report the selected measurement date.

 

 

 

 

Thanks Niels for looking into this. Much appreciated. The API is returning 1558908000000 or Sunday, May 26, 2019 10:00:00 PM GMT. See screenshot below.

As a workaround I've added 12 hours to the date as we just want to report the selected measurement date.

 

 

 

 

Thanks for the feedback. Looks like something in Portal is not working as expected. Careful with the workaround, a similar solution did bite me 6 months after the fix when we entered winter time...

Sounds familiar. I think the issue is AGS saving the datestamp (2019-05-27) as a datetimestamp (adding 12:00:00 AM).

The API returns datetimestamp in epoch in miliseconds: 1558915200000 which equals to 2018-04-11 12:00:00 AM GMT.

Now I'm not sure anymore what did it, but something is correcting your datetimestamp the wrong way around when fixing it from GMT to GMT+02:00.

What date do you get from Portal when you request the record via the rest API?

I tried to reproduce the problem but it is now working like a charm :-| (in both 2016 and 2019) so I'm afraid I can't help at the moment. But I have seen a similar issue.

Got stuck with a similar issue writing data to ArcGIS Online, which needs it to be in UTC... To add time using an attribute manager, just use the following where you replace the timestamp value with your FME formatted date/time string - you need to strip off the timezone from your FME time string as ArcGIS doesn't accept that format, so that's why I used the @Left(,14). It AUTOMATICALLY grabs your local offset based on the settings of your machine, so you don't have to change it twice a year ;): @DateTimeAdd(@Left(@Value(timestamp),14),PT@Substring(@DateTimeNow(local),24,1)H)

@nielsgerrits @annette2

Reply


Community Stats

29,994
Posts
113,940
Replies
37,621
Members
Terms & ConditionsCookie settings