expiration_date returns null in Graphql

[Zignature]

I always get null returned on expiration_date.

My query:

query GetArticle($id: String!) {
  exp_channel_entries(channel: "Articles", entry_id: $id, show_expired: true,) {
    data {
      entry_id
      title
      entry_date
      expiration_date
    }
  }
}

Returns:

{
  "data": {
    "exp_channel_entries": {
      "data": [
        {
          "entry_id": 3,
          "title": "Article 3 Title",
          "entry_date": "2024-06-20 18:00",
          "expiration_date": null
        }
      ]
    }
  }
}

But the expiration_date property should read: "expiration_date": "2024-06-21 00:00".

In this case a specific article is queried, but it also happens when I query all articles. Any help would be greatly appreciated.

My environment:

• Windows 11 Pro (latest build)
• Wampserver 3.3.6
  • Apache 2.4.59
  • PHP 8.1.29
  • MariaDB 10.6.18
• EE v7.4.11
• Coilpack v1.3.2
• Laravel 10.48.17
• Composer 2.7.7

[Zignature]

Nobody?

[TomJaeger]

Thanks for getting in touch about this.. Any chance you can also list any add-ons you currently have in use?

[bryannielsen]

@Zignature I was able to reproduce the error and this fix worked for me - https://github.com/ExpressionEngine/Coilpack/commit/70a57bf254f3375303fac0382493399909f43876

Would you be able to test and confirm on your end? You can include the unreleased changes on 1.x by doing composer require expressionengine/coilpack:1.x-dev. If that looks like a good fix for you we can get it ready for release.

[Zignature]

@bryannielsen yes, that works! 😀

Thank you very much!

[Zignature]

@bryannielsen but there's one "bug", both entry_date and expiration_date are two hours off. I guess timezone set on the EE server (Europe/Amsterdam in my case) isn't taken into account.

I suppose the same will apply to edit_date.

I'm using Nuxt to get and process the data so I'll be able to adjust the time in my code.

[Zignature]

@TomJaeger

Thanks for getting in touch about this.. Any chance you can also list any add-ons you currently have in use?

Only installed add-on is the Rich Text Editor add-on. But, as already established, that wasn't the culprit. :)

[bryannielsen]

@Zignature thanks for testing that and confirming the fix!

The timezone setting you're referring to on the server, is this on the operating system level or in the ExpressionEngine install's General Settings > Date & Time Settings?

I think it provides the most flexibility to return datetimes in UTC format so the GraphQL consumer can decide timezone and formatting but perhaps adding a parameter to the date query for converting the timezone would be a nice addition. Currently you can modify the date format through GraphQL by querying like this expiration_date(format: "c") which will accept any PHP date format characters.

Would it be helpful for your situation if you could query for expiration_date(timezone: "SYSTEM") or expiration_date(timezone: "Europe/Amsterdam")?

[Zignature]

@bryannielsen I am referring to ExpressionEngine's General Settings > Date & Time Settings. Not the settings on the OS level. It makes sense to me those settings are taken into account, but a timezone parameter doing the same thing might be better because it offers a choice.

Like I said before, I can of course format the date in my Nuxt/Vue 3 code :)

[bryannielsen]

@Zignature perfect thanks for the clarification! I think it's a nice feature to have so we added the timezone argument for the GraphQL query. If you want to composer update on the 1.x-dev version you will get the latest commit which allows this in your query

{
      expiration_date(format: "c")
      system_expiration_date:expiration_date(timezone: "SYSTEM", format: "c")
      amsterdam_expiration_date:expiration_date(timezone: "Europe/Amsterdam", format: "c")
}

Maybe this will make it a little easier to format the dates and keep the nuxt/vue code cleaner, just wanted to give you the option :-)

[Zignature]

@bryannielsen

That's awesome! I suppose this works for all dates? Including entry_date and edit_date too? And any custom date fields?

[bryannielsen]

@Zignature yes that's correct, you should have the same formatting options with those dates. Thanks for raising this issue!

[Zignature]

@bryannielsen

You're very welcome. This one can be closed, I guess.

[Zignature]

I updated Coilpack and it works like a charm 😄 Thanks again!

[bryannielsen]

That's great to hear! I was just looking into one other thing before the release but you can change from 1.x-dev back to 1.x in your composer file and get these fixes as part of version 1.4.0

Thanks for your help!

[Zignature]

@bryannielsen you're very welcome and I thank you for fixing and upgrading it 😃

[Zignature]

Unfortunately it doesn't work on custom date fields. The timezone argument throws an error. The format argument doesn't do anything, it just returns an epoch date.

😞

timezone argument error message:

{
  "errors": [
    {
      "message": "Unknown argument \"timezone\" on field \"start_booking\" of type \"ChannelEntry\".",
      "extensions": {
        "category": "graphql"
      },
      "locations": [
        {
          "line": 10,
          "column": 27
        }
      ]
    }
  ]
}

The start_booking field is a Date field with settings:

• Required field?: On.
• Date Localization: "Always fixed". I've tried "Always localized" as well.
• Include time?: On. Also tried Off.
• All other switches are turned off.

I also tried switching from 1.4.0 to 1.x-dev

[bryannielsen]

@Zignature thanks for reporting! I think we need to update the Date fieldtype to use our GraphQL FormattableDate type so that these arguments are available. I will try to tackle that this week for you sorry for the trouble!

[Zignature]

No worries, I'm not in a hurry.

I'm so very pleased there's a GraphQL interface in development now, I'm just glad I can help dig up some "bugs". 😃

[Zignature]

@bryannielsen

@Zignature thanks for reporting! I think we need to update the Date fieldtype to use our GraphQL FormattableDate type so that these arguments are available. I will try to tackle that this week for you sorry for the trouble!

Got around to tackle it yet? No pressure, just curious 😁

[bryannielsen]

@Zignature sorry for the delay on this, I dug into this a little and I think what you're looking for is already supported by the underlying EE field parameters for dates

The formatting is slightly different than the built-in date fields (variables are prefixed with %) so I updated the code a little to handle formatting on these custom fields in a similar manner to the built-in entry fields. You can see that on the 1.x-dev branch if you'd like.

These are what the two queries look like on a date field named test_date

test_date(format:"%Y-%m-%d %h:%i:%s", timezone:"America/New_York") 
new:test_date(format:"Y-m-d h:i:s", timezone:"America/New_York")

[Zignature]

@bryannielsen awesome. I will give it a go tomorrow. I just arrived home from my job at 9:30PM 🙂

[bryannielsen]

Wow that's a long day! No rush, give yourself a break!

[Zignature]

@bryannielsen works like a charm 😃