Skip to content

Error when outputting a leap day date with ISO8601Date type #5311

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jeefujee opened this issue Apr 1, 2025 · 3 comments
Open

Error when outputting a leap day date with ISO8601Date type #5311

jeefujee opened this issue Apr 1, 2025 · 3 comments

Comments

@jeefujee
Copy link

jeefujee commented Apr 1, 2025

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
Copy link
Owner

rmosolgo commented Apr 1, 2025

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
Copy link
Author

jeefujee commented Apr 2, 2025

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
Copy link
Owner

rmosolgo commented Apr 2, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants