Skip to main content
Solved

Portal for ArcGIS Reader date issue - FME reads the date as 2 hours earlier

annette2
Contributor
Forum|alt.badge.img+10

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

 

Best answer by nielsgerrits

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.

View original
Did this help you find an answer to your question?

4 replies

nielsgerrits
VIP
Forum|alt.badge.img+52
  • nielsgerritsVIP
  • VIP
  • Best Answer
  • May 27, 2019

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.

annette2
Contributor
Forum|alt.badge.img+10
  • annette2Contributor
  • Author
  • Contributor
  • May 28, 2019
nielsgerrits wrote:

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.

 

 

 

 

nielsgerrits
VIP
Forum|alt.badge.img+52
annette2 wrote:

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...

runneals
Contributor
Forum|alt.badge.img+19
  • runnealsContributor
  • Contributor
  • May 28, 2019
nielsgerrits wrote:

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


Most helpful members this week

Community Stats

30,845
Posts
116,934
Replies
38,666
Members
Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.