Latest Contributions by RJSunderman

Hello @JessicaRouns.  What you describe, I think, is a limitation of the spatiotemporal data store's map service implementation. You are correct that you cannot use GeoEvent Server to edit or specify feature record symbology. Because the GeoEvent Manager web application can be used to publish map and feature services, both when using a spatiotemporal data store as well as a traditional relational geodatabase, it is reasonable to see this something the GeoEvent Server product team could address. But I would suggest that GeoEvent Server's role in this scenario is limited to writing data from processed event records out to feature records using the web service as an interface to the geodatabase. I will bring this up with developers familiar with the spatiotemporal data store's map service implementation. However, since configuring symbology for feature record display is more part of web service publication and web service specification, not GeoEvent Server, I would suggest you try asking this question on the ArcGIS Enterprise Questions board or perhaps submitting it as an enhancement request to ArcGIS Enterprise Ideas. You can mention @jill_es, one of the product managers for ArcGIS Enterprise, and she can help direct the conversation to the right team. Thanks -- RJ ... View more

To answer your question we should first take a look at the raw data GeoEvent Server is receiving. The date/time values associated with sensor data are highly adaptable and can be represented many different ways. Your question mentions receiving data from Verizon Connect, so let’s look at some sample data from that sort of data feed. The illustration above left shows a sample of raw JSON data typical of what Verizon Connect might send. Note the UpdateUTC data value is sent as a 13-digit epoch value in milliseconds. When a GeoEvent Server input receives data in this format and adapts it as a Date the epoch value is assumed to represent a Coordinated Universal Time (UTC) value, not a local time value such as Mountain Standard Time (MST). So to clarify a point in your question, data is not received as MST values. It is received as an epoch long integer value and adapted, first for processing as a Date data type, and later for display as a string. The second illustration, above right, shows an online date/time utility I often use to convert epoch long integer values to human-readable string representations of a given date and time. Note that the strings constructed by the utility specify an offset from Greenwich Mean Time (GMT). GMT and UTC never change for Daylight Saving Time (DST) and are sometimes used interchangeably even though GMT is technically a time zone and UTC is a time standard. A display string constructed from the epoch 1676597835000 can specify a time zone. For example, an application might construct a string to display a date and time as February 17th 1:37:15 AM (GMT) or display a local time February 16th 6:37:15 PM (MST). Note that when the epoch converter displays a local time value a time zone offset is included in the string. Client applications generally determine how they want to construct and display string values representing a date and time. GeoEvent Server uses epoch long integer values for its Date values when processing data, and at times converts the Date into a human-readable string for display in the server’s local time zone. To your original question, the UpdateUTC data value is not changed when written to the database. The Date value in a geodatabase feature record is always going to be an epoch long integer value consistent with the ArcGIS REST API. Verizon Connect sends the date/time of a vehicle position report as a UTC value, and that is how the value is being stored in the database. Why a date/time value displayed by the GeoEvent Sampler appears different, for example, than the same value written out to a CSV file or a JSON file is a question of data adaptation and string construction. Rather than displaying the actual epoch long integer value of a Date (such as 1676597835000) GeoEvent Sampler constructs and displays a string representation of the Date using your server’s locale to determine an appropriate time zone. That is why you see the time zone MST included in the GeoEvent Sampler’s displayed string "Thu Feb 16 18:37:15 MST 2023". When you configure a Write to a CSV File output you choose whether date/time values are written out as ISO 8601 formatted values or as strings in a custom format. The Write to a JSON File output, on the other hand, cannot be configured to write out a human-readable string. When reviewing the JSON output file in a text editor you will see the actual epoch long integer value of a Date. I’ll include some examples in the comments below to illustrate how you might expect different client applications to construct display strings from epoch long integer values stored in a geodatabase feature record. But to answer the last part of your question, how do you fix what you are seeing, that depends entirely on what you are trying to do. The epoch long integer underlying a Date cannot express a time zone or an offset from UTC the way a String value can. You could configure a Field Calculator or Field Mapper with an expression that either adds or subtracts a number of hours from a Date value, but I really do not recommend this. If you fudge a Date value to shift it from UTC into a local time zone you risk a client application downstream, possibly one outside the ArcGIS Enterprise, constructing a string from an epoch value it assumes is a UTC value and displaying a string which appears incorrect. Suppose, for example, you are using an application like SQL Server Management Studio (SSMS). When the application retrieves a Date whose value you have explicitly offset, it will likely assume the value it retrieved is a UTC value, use your server’s locale to determine an appropriate time zone, and apply the temporal offset a second time. The Date value you explicitly offset by a number of hours as part of your event record processing in GeoEvent Server now appears incorrect when viewed using SSMS. For the simple reason that a database server can be in any time zone, and web client applications that access the data may not be in the same time zone as the server, the recommended best practice is to keep the ArcGIS REST API default and allow feature services to maintain Date values as epoch long integer values in the assumed UTC standard. If you want to calculate and store a local representation of a Date value, calculate the value as a String. You can use the toString( ) function in a Field Mapper, for example, to do this. A String value is a literal string and won’t ever be manipulated to change its value. This might be ideal for displaying attribute values in a web map pop-up, but you cannot use attributes of type String to configure something like the time slider in ArcGIS Pro. Instead of computing a String value, or adding/subtracting a number of milliseconds from a Date value, the best approach working with ArcGIS Pro would be to configure its feature layer properties to apply a time zone offset to Date values it retrieves from a geodatabase. As you zoom, pan, and potentially change a map’s temporal extent to see more or fewer features, the date and time strings displayed by ArcGIS Pro should reflect local time rather than a UTC time. ... View more