Hoppa till huvudinnehållet

Using System Date/Time

Kommentarer

15 kommentarer

  • Phil MacIntyre

    Hi Brian,

    This is Phil from the Mobile team. Thank you for your question.

    Is there a time difference between your user's device and the server your SDE is being hosted in? We've seen some issues in the past where you can force a specific time into the data's hosting environment which appears to be different from the device collecting the data. For example, say my server was set to use Eastern Standard Time and my user collected data in Pacific Time, then a 9am time stamp to my user would correspond to a 12pm time in my server.

    A useful check would be to sign into your Portal which is hosting your web map from your device, collect a time stamp using the Portal's map viewer, and then compare the listed time to what's stored in your SDE table (essentially ruling Mobile out of the equation to see if it's the server configuration which is the issue).

    Hope that helps,

    Phil

    0
  • Brian Bulla

    Hi Phil,

    Ok, so as a quick test I just updated the pop-up for the Hydrant layer in our webmap that Mobile is using, and it seems to be showing the Date/Time properly.  See the screenshot below.  So does this mean the issue is with the Mobile app when the save is happening??

    0
  • Phil MacIntyre

    Hi Brian,

    Yes, it does appear that the issue is in Mobile. That looks to be an Arcade expression you've got there, so I wouldn't expect that to work in Mobile (we don't have support for Arcade at this point), but I think that's a separate issue here.

    Does the 4 hour difference correspond to the time difference between your location and UTC? We recently had a bug identified by our Support team where Mobile's out-of-the-box add/edit feature tools are able to handle this correctly, but using Workflow forms you always get the UTC value returned rather than your time adjusted one. It's high up on our priority list to fix but will still be a little while before we can get to it.

    A workaround that our Support team identified was to use the Format Date activity on a date-time passed in and make use of its Unix output to set the date-time field in your display form, like so:


    The Unix value returned does adjust for time zones. Perhaps try adding that activity into your Workflow auto-population process?

    Phil

    0
  • Brian Bulla

    Hi Phil,

    Yes, 4 hours is the difference between UTC and EST so it must be storing things as UTC in the database.  Is there an ETA on the bug fix?

    For this workaround, I can't seem to find where this Output to unix would be.  Can you provide some guidance on where to find it?  I'm looking at the form in Workflow but don't see it there, and I'm also looking at the field itself, but don't see it there either.

     

    0
  • Phil MacIntyre

    Hi Brian,

    Our team is currently tied up with doing a major upgrade to our platform to support Esri's new 200.X series Maps SDK, but I'll see if we can look for a fix in the next release or two (releases coming approximately every 2 months).

    To get the workaround, you could configure a load event on your 'Inspection Date/Time' field and make use of the 'Set Form Element Property' activity, like so:

     

    Your 'Format Date' activity could be further upstream in your Workflow, or you could embed it into the load event itself.

    Please let me know if you have any other questions,

    Phil

    0
  • Brian Bulla

    Hi Phil,

    Thanks for helping with this.  This is really my first day using GeoCortex.  I'm taking over an old abandoned project.  So I've updated the Load event on the DateTime picker, but getting this error in Mobile:

    Previously I had =Date.now() in there, but with =$date.unix I get the error.  

    0
  • Brian Bulla

    Hi Phil,

    Also, I threw this out to the esri community just in case it's something on the back-end.  What do you think of this reply from Ayan at the end of the thread?  Do you think it might be a setting on the webservice TimeZone that could be causing the issue??

    https://community.esri.com/t5/geodatabase-questions/saving-date-time-to-a-date-type-field/m-p/1331047#M8604 

    0
  • Phil MacIntyre

    Hi Brian,

    No problem at all. Workflow's a super powerful tool but does take a bit of learning to really wrap your head around.

    That '=$date.unix' output is the expected output from the Format Date activity. So rather than piping in the '=Date.now()' method directly to your date-time field, you'd want to pipe it into the Format Date activity, then the output of the Format Date activity into that 'Set Form Element Property' activity, which in turn would set the value for your date-time field.

    I cooked up a simple example, just a display form with a date-time picker in it. The date-time picker has a load event, and its subworkflow looks like this:

    With the Format Date activity configured as:

    And then the 'Set Form Element Property' activity like so:

    Where the element is simply that date-time picker. It then appears in my form like this when I run the Workflow:

    Please let me know if you have any other troubles.

    Phil

    0
  • Phil MacIntyre

    Hi again Brian,

    With regards to Ayan's comment, he's correct that there are server-side settings which can result in times appearing to be different. However, Mobile should respect those settings. The ultimate test would be to see if something that's saved in Mobile is being incorrectly saved in the database, a destructive action. If it's working as expected, then that 8:22am you see in Mobile while on the east coast should appear as 12:22pm in the server, assuming it's set to UTC (or defaulting to UTC).

    It would be problematic if simply opening a feature in Mobile and saving it caused a time change. We've seen that before (like in the issue our Support team encountered that I described above). In that case, every time the user saved a feature, it was changing the time by hours equal to the time zone difference, so it was fundamentally, permanently altering the data rather than just displaying it differently.

    Time zones and different server settings are certainly tricky! We'll do our best to get you sorted out though.

    Phil

    0
  • Brian Bulla

    Hi Phil,

    OK, thanks.  I got that to work properly now.  Unfortunately still in the Mobile GUI, "Yes" I am getting the correct value, but in the table that the data is getting saved into it is still showing up in UTC.  The populated Date/Time in that field in Mobile was at 2:39PM but is getting saved as 6:39PM in the SDE table.

    Maybe it is a problem with the webservice like the guy from esri was saying??

    0
  • Phil MacIntyre

    Hi Brian,

    Yes, I think you might be right. The data isn't technically wrong, it's just not being displayed in a manner that's appropriate for your location. I think his post included some guidance for making adjustments to the web service, so that it'll display in eastern time rather than UTC. Hopefully that will get things all sorted out for you.

    If there are any other questions or concerns though, please don't hesitate to ask. Have a great day!

    Phil

    0
  • Brian Bulla

    So an update on this....once the webservice was changed to the proper Time Zone, then the data saved to the table with the proper date/time.  

    But oddly in the VertiGIS form I have a dropdown where I show all of the recorded INSP_DATE for the selected feature.  

    Once a date is selected the rest of the form fills in with all the recordings from that selected inspection.  One of the fields I show is also the INSP_DATE, but in a Text Box and when I use INSP_DATE.toString(), it actually shows in the proper time, whereas the same INSP_DATE in the drop down (not .toString()) is showing in UTC.

    Any idea what might be going on??  Basically I just want both to show as EST, which is the TimeZone of the webservice.

    Does .toString do something to the formatting??

    0
  • Jeff Siemens

    Hi Brian,

    Phil asked me to help out with this one.

    The short answer is that you should just call .toString() in the expression, which gives you the result you're looking for. You can also call any of the other methods on a JavaScript data object, such as "toLocalString()", which would format the date format you with the hour offset from UTC. You can get a listing of the different methods available here. 

    https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleString

    Some of them may not work since it's not a full implementation of the entire Date class.

    Another option is that you can use the 'Format Date' activity to format the date according to different formatting options.

    The background for happening here, if you're interested, is that when you call .toString() it's executing the JavaScript version of toString() which produces a certain result, but if you don't call .toString(), then it's passing the full DateTime object into the activity, which is running in .NET, and then the .NET code is calling .ToString() which is a .NET implementation of ToString() which produces a different result than the JavaScript version.

    Jeff

    1
  • Brian Bulla

    Hi Phil/Jeff,

    Thanks for your insight.  I think I understand what you are saying.  Now to take this on a bit of a tangent, what I am trying to do is to populate a drop-down with a bunch of dates of historical inspections.  Then the user selects a date, and they can view that old inspection.

    So far, I have a form and if the user selects "Review/Update Old Inspections" I have a workflow that triggers on the "OnChange" event of the radio group that will load up that drop-down box.  I'm using a version of the ArcGIS Query Template to populate the drop down with the results of a query on the Inspection Table to get all the dates.  I don't quite understand where in that workflow I will do the .toString().  Can you give some insight?

    Right now in the "Get Form Element Items From Features" I am trying this in the "Label" field:

    =$fldINSP_DATE.result.toString()

    0
  • Phil MacIntyre

    Hi Brian,

    With the default ArcGIS query template, I suspect your problem there is that the result is an object, containing multiple properties, rather than just a simple date that you could use the toString() method on. If you use that Workflow inspector tool I mentioned before (the one in the log viewer, when you have debug mode on), and inspect the output from the 'Get Form Element Items From Features' activity, you may be able to determine the specific field name you want to pull the date field from. For example, when I drill into the default query template's output, referencing the US states, and I wanted to work with a specific attribute, I could do something like so:

    So to harvest that 'Count' integer, I would use an expression something like:

    =$formElementItems1.Outputs.items.Value.Attributes{"Count"}

    To then work with that value, and iterate through the list, I could put a 'For Each' activity in between the 'Get Form Element Items From Features' that takes that 'Items' input type. The For Each could use a 'Format Date' activity to get it into the format you want. Then I'd pipe the output of the 'For Each' activity into the 'Set Form Element Items' activity (since it wants an input of type 'Items' as well), which should hopefully allow you to use that adjusted date value.

    A couple of avenues for you to explore at least,

    Phil

    0

Du måste logga in om du vill lämna en kommentar.