TECH

Graphql-ruby and passing ISO8601 DateTimes without timezone

blogpost

If you are writing web apps for some time, you had to encounter at least a few issues/situations when you had to deal with Timezones. If you are a Ruby developer, and you use Ruby on Rails then you are probably familiar with the difference of Time.now, Time.current and Time.zone.now. (if not, that is quick blogpost for one of those teams that are setting the standard of how to write Ruby code : https://thoughtbot.com/blog/its-about-time-zones)

Conclusions of that blogpost (and many others) are simple: use those methods that are referring to your app timezone and do not mess with that if you want to have smooth to maintain time-related code.

Now, let’s focus for a moment on a gem that helped a lot of us to have a nice time during working with our graphl API: https://github.com/rmosolgo/graphql-ruby.

What is easy to forget, that this gem is for all ruby applications. Not only for rails-based.

If you are thinking about that gem as an addition to your rails app that is following “standard” approaches: remember that this gem doesn’t have access to Rails DateAndTime::Zones class for example.
That is Time class ancestors from gem:

$: Time.ancestors
=> [Time, Comparable, Object, ErrorBubblingHelpers, Minitest::Expectations, PP::ObjectMixin,
 JSON::Ext::Generator::GeneratorMethods::Object, Kernel, BasicObject]  

and that one is how Time ancestors looks like if we load default rails console:

$: Time.ancestors

=> [Time, DateAndTime::Compatibility, DateAndTime::Calculations, DateAndTime::Zones, Comparable, ActiveSupport::ToJsonWithActiveSupportEncoder, Object, ActiveSupport::Dependencies::Loadable, PP::ObjectMixin, JSON::Ext::Generator::GeneratorMethods::Object, ActiveSupport::Tryable, Kernel, BasicObject]  

Why is it important? Because when you realize that, you can assume and check it in the gem codebase to be sure how exactly it works if it comes to ISO8601DateTime types when they don't have a TimeZone passed from client side.

As you probably already suspect - it parse it using server timezone, not application timezone (because it doesn’t have access to it by default).

Conclusion:

Remember that graphql-ruby is a gem prepared not only for rails environment, so do not expect it will be operating on your rails app timezone. Ensure that your system have the same timezone as your app, and enjoy graphl-ruby gem, as you were before!

P.S. (few tips for setup that we mostly work with)

  • App To change timezone in app, go to config/environments/.rb and set:
config.time_zone = "UTC"
  • System To change linux based system timezone just run
 sudo ln -fs /usr/share/zoneinfo/UTC /etc/localtime
  • Postgres Database
    • Run psql
    • show config_file;
    • because SET TIME ZONE 'UTC; -from psql will work only until next restart of postgres to change timezone open config file and set
  timezone = 'UTC'

Read more on our blog

Check out the knowledge base collected and distilled by experienced
professionals.
bloglist_item
Tech

Over the years I had to deal with applications and system that have a long history of already being "legacy".
On top of that I met with clients/product owners that never want you to spend time ref...

bloglist_item
Tech

How many times have you searched for that one specific library that meets your needs? How much time have you spent customizing it to fit your project's requirements? I must admit, waaay too much. T...