graphql-scalars icon indicating copy to clipboard operation
graphql-scalars copied to clipboard

fix: Unix timestamps are not serialized correctly for scalar DateTime

Open yamatsafi opened this issue 1 year ago • 6 comments

Description

The DateTime scalar (GraphQLDateTime) fails to convert unix timestamp, for example, 1695416400, produces a date like 1970-01-20T14:56:56.400Z. Since the Unix timestamp represents the number of seconds since January 1st, 1970 at UTC, and the Javascript Date() function's [Time value or timestamp number] argument is in milliseconds, not seconds, the number of seconds needs to be multiplied by 1000.

In javascript, if one tries to convert a UNIX timestamp into an iso human-readable date string, one must do:

const humanReadableDate = new Date(1695416400 * 1000).toISOString(); // result 2023-09-22T21:00:00.000Z

Related # (issue) #2139

Type of change

  • [x] Bug fix (non-breaking change which fixes an issue)

Screenshots/Sandbox (if appropriate/relevant):

Screenshot 2023-09-23 at 10 23 46 PM

How Has This Been Tested?

  • [x] Test A Screenshot 2023-09-23 at 10 23 46 PM

  • [x] Test B Changing this particular line in the library locally fixes our issue.

Test Environment:

  • OS: macOS (Ventura 13.5.2) / Docker in Red Hat Enterprise Linux Server release 7.9 (Maipo)
  • GraphQL Scalars Version: 1.22.2
  • NodeJS: 18.7.1

Additional context

  • Our stack is a nodejs with fastify v4 and the following:
  • "graphql": "^16.8.0",
  • "graphql-scalars": "^1.22.2",
  • "@graphql-tools/schema": "^10.0.0",
  • "@graphql-tools/utils": "^10.0.6",

Checklist:

  • [x] I have followed the CONTRIBUTING doc and the style guidelines of this project
  • [x] I have performed a self-review of my own code
  • [x] I have commented my code, particularly in hard-to-understand areas
  • [x] I have made corresponding changes to the documentation
  • [x] My changes generate no new warnings
  • [x] I have added tests that prove my fix is effective or that my feature works
  • [x] New and existing unit tests and linter rules pass locally with my changes
  • [x] Any dependent changes have been merged and published in downstream modules

Further comments

This change is more in line with graphql-iso-date package.

yamatsafi avatar Sep 22 '23 23:09 yamatsafi

This is a breaking change and i am not sure if I want to sacrifica the support for the other timestamp format.

ardatan avatar Sep 24 '23 21:09 ardatan

This is a breaking change and i am not sure if I want to sacrifica the support for the other timestamp format.

Not sure how this is sacrificing support for other timestamp formats, but this needs to be addressed as it doesn't work for unix timestamps. Fixed broken tests.

yamatsafi avatar Sep 25 '23 14:09 yamatsafi

This is a breaking change and i am not sure if I want to sacrifica the support for the other timestamp format.

Not sure how this is sacrificing support for other timestamp formats, but this needs to be addressed as it doesn't work for unix timestamps. Fixed broken tests.

Arda, any further thoughts on this?

yamatsafi avatar Sep 29 '23 14:09 yamatsafi

@ardatan added support for both seconds and milliseconds. I would appreciate it if you could take a look, please.

yamatsafi avatar Oct 24 '23 22:10 yamatsafi

@ardatan We've just discovered this issue as well. Any chance of merging this?

jeremyzahner avatar Apr 15 '24 10:04 jeremyzahner

https://github.com/Urigo/graphql-scalars/pull/2141/files#diff-5bff20d592f8d56ae20cad088bf374d5ce38af414afd5631ab82f42481bb8473L90 This only tests the new behavior but no longer tests the old behavior. Could you update the tests without touching the old tests, then we can merge and release?

ardatan avatar Apr 15 '24 11:04 ardatan