Aller au contenu principal

Comparing dates in query activity

Commentaires

6 commentaires

  • Ken Lyon

    S. Burgert The issue is to do with the difference between SQL dates and JavaScript dates. The numerical value you see is the underlying value within a JavaScript date, but it's not going to work in a query.

    Your “Where” field would need to look something like this:
        ="Date > ‘2023-08-08 00:00:00’"

    You would need to use the various methods of Date via $date1.date to get the year, month, day, hours, minutes and seconds. You might also need to set Use Utc to true if the source data is stored as Utc dates.

    0
  • S. Burgert

    Hi Ken, 
    Thanks for the tips. I was able to solve the problem using an Arcade script ($CalculateDate) containing the following code:

    var now = Now();
    var twoYearsAgo = DateAdd(now, -2, ‘years’);
    return Text(twoYearsAgo, ‘YYYY-MM-DD HH:mm:ss’);

    I then created the Where clause in the query as follows:

    = “Date < DATE ‘” + $CalculateDate.result.toString() + “’”

    As you can see, the DATE function was missing from your suggestion. I also had the problem that your (american?) single quotation marks were misinterpreted, and I had to replace them with the single quotation marks on my keyboard. It took me quite some time to figure that out :)

    All in all, it is still surprising that the built-in “Calculate Date” function does not return a date format that can be used for further processing. Instead, you first have to manually adjust it, which is cumbersome.

    Kind regards

    Sinje

    0
  • Ken Lyon

    Hi Sinje,

    Thanks for your response. I realize now that I completely forgot about an activity that would have helped a lot with this: Format Date

    You can specify the format you want such as “YYYY-MM-DD HH:mm:ss” and get back the appropriate string.

    We intentionally kept Calculate Date and Format Date as two separate activities as they serve different purposes.

    Regarding the characters used in my example - I think the text editor here tried to make the quotes more fancy. I had used the apostrophe which should have appeared as a single quote, as used to represent a string in SQL.

    That's interesting you needed to cast it to a DATE in your WHERE clause. I've not seen the need for that before.

     

    0
  • S. Burgert

    Hi Ken, 
    I found the Format Date function, but thought I could only generate the outputs specified in the help section, which wouldn't have helped:

    Now I tried to implement your suggestion and specified “YYYY-MM-DD HH:mm:ss” as the format in the Format Date function. However, the output then looks like this: 2023-08-12T08:13:55.000Z. Unfortunately, this is then again not compatible with the time format from the ESRI database.

    0
  • Ken Lyon

    Hi Sinje,

    The important part was just below the area in your screenshot:

    For your case, we'll be using the custom date and time format strings. (https://learn.microsoft.com/en-us/dotnet/standard/base-types/custom-date-and-time-format-strings)

    It's important to note this is case-sensitive.

    You would need to use “yyyy-MM-dd HH:mm:ss” because the year and day need to be lower-case.

    Finally, the output you showed looked like it came from the “iso” output. You need to use the “formatted” output to get the value in your custom format.

    I hope this helps.

    0
  • Berend Veldkamp

    Ken Lyon That DATE is not really a cast, but a function. It is documented by Esri here: https://www.esri.com/arcgis-blog/products/api-rest/data-management/querying-feature-services-date-time-queries and here: https://developers.arcgis.com/rest/services-reference/enterprise/query-map-service-layer 

    These pages have some useful information about date queries, including querying by current date, or using an interval. If leap years are not important, the OP's query can even be simplified to: 

    date > CURRENT_DATE - INTERVAL '730' DAY

    Year does not seem to be a supported interval, unfortunately

     

    Also note that dates in queries should be in UTC, not local time, because that's how ArcGIS stores dates (unless you changed that to local time). Depending on the timescale, and where you live, that may or may not be relevant.

    0

Vous devez vous connecter pour laisser un commentaire.