Error when outputting a leap day date with ISO8601Date type

[jeefujee]

Describe the bug

Using GraphQL::Types::ISO8601Date on a custom type's field can produce an invalid_date error when renderer if the field is a Date object set to 2024-02-29.

After analysis, it appears that value.to_s output Tue 29th Feb., and Date.parse(value.to_s) crash with an invalid_date error because the year is not present in the input argument (which is necessary for leap days).

Versions

graphql version: '~> 2.3'
rails (or other framework): '6.1.7.10'

GraphQL schema

Include relevant types and fields (in Ruby is best, in GraphQL IDL is ok). Any custom extensions, etc?

      class CustomType < GraphQL::Introspection::BaseObject
        field :id, ID, null: false
        field :date, GraphQL::Types::ISO8601Date, null: true
      end

GraphQL query

Example GraphQL query and response (if query execution is involved)

query {
  custom { id date }
}

Steps to reproduce

• Define a model with GraphQL::Types::ISO8601Date field
• Plug this model to a data entity that map a Date object with the date field. The date should be on a leap day (ie. Date.new(2024, 2, 29))
• Try to render the model with this data entity through the GraphQL api

Expected behavior

• It outputs the model with the date renderer as a ISO 8601 string (2024-02-29)

Actual behavior

• It produces a 500 error, subsequent error is invalid_date

[rmosolgo]

Hi! Sorry for the trouble. I'm not able to replicate this yet. I tried in IRB but Date.new(2024, 2, 29).to_s outputs something different for me:

$ irb
irb(main):001> Date.new(2024, 2, 29).to_s
=> "2024-02-29"

I wrote up a little GraphQL-Ruby script but it works as expected for me:

require "bundler/inline"

gemfile do
  gem "graphql"
end
require "date"

class MySchema < GraphQL::Schema
  class Query < GraphQL::Schema::Object
    field :leap_day, GraphQL::Types::ISO8601Date

    def leap_day
      Date.new(2024, 2, 29)
    end
  end

  query(Query)
end


pp MySchema.execute("{ leapDay }").to_h
# {"data" => {"leapDay" => "2024-02-29"}}

Are you using Rails? Maybe some Rails or other local configuration is changing the output of Date.new(...).to_s?

I'm interested in addressing this, but I'll need a failing replication first. Let me know what you find!

[jeefujee]

Hey ! Thank for the swift answer. 😄

It appears that in our codebase, we override the default to_s format for Date and Time as:

Date::DATE_FORMATS[:default] = "%a %b %e %Z"
Time::DATE_FORMATS[:default] = "%a %b %e, %l:%M %p %Z"

My bad, it's my fault for not noticing this. But it still make the ISO8601Date type a bit problematic for those that replace the default Date::to_s format.
I understand it's an edge case, but I think maybe you could use the same logic as ISO8601DateTime which seems more reliable by reusing the Date object directly without relying on string parsing?

[rmosolgo]

Yes, I'm definitely open to that improvement. Want to give it a try?

[rmosolgo]

I had a hard time writing a test for this .... it turns out that Rails 7 deprecated its override of Date#to_s (https://github.com/rails/rails/blob/de7c495209811f8f918fa9f915e64df61a6080c1/guides/source/7_0_release_notes.md#deprecations-8). Rails 6 is EOL (https://rubyonrails.org/2024/10/15/new-maintenance-policy-and-eol-annouments). I don't plan to investigate this issue anymore, however, if you want to work up a patch and a test, I'm open to merging it and releasing it!