Date format question
I have a feature in a layer that has a 1/1/1981 date, but when I do an Identify, it comes out as 12/31/1980. If I go into the layer confinguration in Manager and on the field tab change the Data Time Zone to Pacific Time, it works correctly. The problem is, from my reading of the Admin Guide, this setting should be for how the data is stored, not how it is displayed, so it really should be UTC.
0
-
In the Site Information there are Data Time Zone and Display Time Zone fields. Have you tried adjusting those? 0 -
Yes, I checked there - everything there is set to Default. Likewise on the Display Settings tab for the Service. I also did a search of the Site.xml for TimeZone, and it only occurs on the one layer that I set to Pacific Time... 0 -
You should try to adjust those fields in the Site Information and see what that does. Even though your layer is only showing that date (1/1/1981) it is probably storing the time as well and adjusting based on the time zone settings. 0 -
Yes, they do have time, and it is a zone adjustment... My question is why is it doing it!? I've changed it in various places, but putting everything to default, and only changing it at the layer lever gets it to display properly.
The documentation implies that at the layer level, the "Data Time Zone" should be what the data is stored at, not what I want it to display as. To me, this means I should be putting in UTC instead of Pacific.0 -
Hi Mike,
Essentials assumes to store all date/time data from a feature attribute or ArcGIS table in UTC, by default. For display, date/time will be adjusted to the user's local time by the viewer by default.
The settings mentioned in a comment above, Data Time Zone and Display Time Zone, allow you to go a step further and specify how date/times are handled when it comes to storage & display. These options are available for further customization, for users who have other systems that make use of this data and might want to adjust accordingly.
For your environment, it certainly sounds like you should have Pacific for Data Time Zone. I'd recommend leaving the Display Time Zone as default.
I hope this explanation helps to clarify the workings of these formatting options.
Thanks,
Aaron Oxley0 -
OK - to extend this further- where I'm currently pulling my hair out!!
I've added a feature fine, it saves as local time (UTC+11).
I have identify enabled on two layers: the Edit layer, and the 'normal' layer that is created by this edit layer
so I do an identify on that point (which is two points really)
the create date of the 'normal' layer is Nov 2, 2017 2:41 AM
the create date of the 'edit' layer is Nov 2, 2017 1:41 PM (the correct time!)
so why is a normal layer showing a different time to the edit layer equivalent! I've tried all types of combinations of both Site settings and layer setting with the above mentioned items. I have currently set the two layers to the TimeZoneID="Australia/Canberra" and I still get this discrepency..
any advice appreciated
regards
Gareth0 -
Hi Gareth
Not sure whether this might help you, but we were experiencing a simlar issue (although ours was the the time of the editable layer) when capturing data using Collector. What we did was to enable time on the Layer properties in the mxd and set the appropriate time zone in the advanced settings.
Cheers
Chris0 -
I'll just add, that the Silverlight viewer displays the correct time across both the edit and normal layers. 0 -
Chris, I went checking the time settings in the mxd last night, and there wasn't anything set. It's worth a try I guess, but it's so strange that the Poly and Line equivalents are all fine with displaying dates, but the Point layer isn't - which adds further complexity to this problem.
We might rebuild the mxd, and the feature class from scratch and see how that goes!
thanks for the suggestion
Gareth0 -
We found the culprit - what a doozy!!
It ended up being some legacy time settings on the map layer in the mxd. YET, the time enabled was not active!!!!
For some reason the details of an old time offset setting (0 hrs) which was ghosted out in the properties view, and unticked, and therefore inactive (in theory) was used in the published map service...
Probably one of the more stranger things I've seen :(0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
10 Kommentare