Closed smalers closed 4 years ago
After some thought, I have the following suggestion for the attribute formatting, where the horizontal line is an HTML hr element. I recommend showing the time in the local time zone of the computer rather than Z time. Or, use the offset from Z time. Using offset time is shorter so may be desirable to prevent wide dialog.
CreateDate: 1598095090359
+CreateDate: 2020-08-22 13:23:00 America/Denver
+CreateDate: 2020-08-22 13:23:00 -06:00
..other attributes...
----------------
+ auto-generated values
The current time for the computer could be added to the bottom of the Help/About popup, for example, as follows. Use the same time so that the user clearly seems that -06:00
is the same as America/Denver
.
Current time (offset from Z): 2020-08-22 12:23:00 -06:00
Current time (local timezone): 2020-08-22 12:23:00 America/Denver
The date conversion has now been updated for both mouseover and clicking on a feature. Closing this issue.
The wildfire perimeter layer read from FWS is showing times as UNIX epoch integers wheres before it seemed to be a formatted date/time string. It is therefore difficult to know when the data were updated.
It may be possible to do an SQL query to the service, to convert to a date/time string using an SQL function. However, that may involve selecting each of the fields manually in the SQL, which is cumbersome since we don't control the data and attributes may change. It may be possible to check the type of the value returned so that the SQL is generic, but that may take some work.
Another option would be to auto-detect attributes with
date
,time
, ordate/time
in the attribute name, and large integer value. If found, the epoch time could be converted to a date/time in UTC by default, or even convert to computer's local time. This is probably a pretty safe assumption. To be safe, the popup could show as a new attribute with appropriate name.Later, when we enhance the popup formatting (another issue), we can put more energy into this.