Web Map not showing same date as published mxd

3796
5
Jump to solution
07-09-2014 05:55 AM
ErikBlake
Occasional Contributor III

So we have a tool we run each morning that updates a table with information that our meter tech people need. this table is joined to a meter location layer that is in our sde. But because you can't publish a joined layer our tool creates a new FC out of the join and puts the new FC in a file GDB. We then have this mxd published to our AGS then we created a web map on AGOL that hits this service. Then our meter tech people use their iPads to access the web map with Explorer. Everything seems to work fine. the new data that is updated every morning is reflected in the web map. For example we had 311 records yesterday in the published mxd. and we had 311 records showing up in the web map. And today we ran the tool and we had 322 records in the mxd and 322 records in the web map.

However. one of the fields in our table in the new FC that was created from the join is called "Read date" we can't seem to figure out why this is different in our published mxd and our web map. the web map table always reads a day behind. So for example we ran the tool today and the field has a read date of 7/9/2014 but whne we look at the same table in our web map it reads yesterdays date of 7/8/2014.

We do know that the data is being updated because we compare and look at both data sets. it's just the weird date thing going on.

Anybody else experience this issue.

Erik

Tags (2)
1 Solution

Accepted Solutions
RobertScheitlin__GISP
MVP Emeritus

Eric,

   This is a common problem with ArcGIS Server, date fields, and web mapping. The solution is also simple. Likely right now your data has a date field with just the date and by default it sets the time to midnight and thus when a web map adjusts for the timezone of the client app it will move that date based on the UTC date/time + or - the time zone. So all you need to do is set a predefined time to all your date field info, say 06:00:00.

Robert

View solution in original post

5 Replies
RobertScheitlin__GISP
MVP Emeritus

Eric,

   This is a common problem with ArcGIS Server, date fields, and web mapping. The solution is also simple. Likely right now your data has a date field with just the date and by default it sets the time to midnight and thus when a web map adjusts for the timezone of the client app it will move that date based on the UTC date/time + or - the time zone. So all you need to do is set a predefined time to all your date field info, say 06:00:00.

Robert

ErikBlake
Occasional Contributor III

Thanks Robert. I appreciate your help. I marked as helpful and click the "mark as correct" so you will get points. I hope I did it right. this new set up is confusing as "HE double hockey sticks."

0 Kudos
RobertScheitlin__GISP
MVP Emeritus

Erik,

   Yep it will take some getting use to but it seems like it will be a great site once we get past the learning stage. You did it exactly right.

0 Kudos
MikeMinami
Esri Notable Contributor

Servers store dates in Coordinated Universal Time (UTC). If you don't specify a time zone for your data, it is assumed to be UTC. Web browsers convert the date to local time. Thus, the time offset changes the date display in popups. For example, if you are located in California during standard daylight time, what you see is 8 hours earlier (UTC-8) than the time in the data. Thus a date of 7/7/2014 12:00 a.m. would be converted to 7/6/2014 5:00 p.m. by the browser.

When you publish your data from ArcMap, you can set the time zone on a layer in Layer Properties (Time tab). Because you are providing the time zone, the server will correctly convert local time to UTC time when storing it on the server. Then, no matter where you are in the world, the browser will display the correct time, for the particular time zone. In your case, it probably doesn't matter, But for example, if you're dealing with earthquake data, a web map would correctly indicate that an earthquake happened at 6am California time, but show 9am in New York.

Hope this helps,

Mike

ErikBlake
Occasional Contributor III

Mike

You helped a lot. Thanks for the explanation.

0 Kudos