Events dates are off by one day when running locally

[sebsto]

When running the web site locally, all events are off by one day.
I guess this is a due to a local timezone, my laptop is running in

Central European Summer Time
Time zone in Paris, France (GMT+2) 

Here is a screenshot of the hosted version :

Here is a screenshot of my local version :

[harrysolovay]

@sebsto thank you for calling attention to this. We'll hopefully be able to internationalize soon. Incase you wanted to take a crack at it, a PR would be tremendous (& if not, no worries 👍 ).

Any library recommendations? react-intl and react-i18next seem to be popular solutions. It would be great to hear your thoughts.

Thanks again for submitting this issue!

[harrysolovay]

@sebsto I'm curious if you're still running into this problem––seems like the problem was in part caused by the way newsletters were being generated. We re-created the generation mechanism last week. Hoping this is now resolved.

[sebsto]

Thanks for getting back to me. Yes, I still observe the same with latest code in master branch.
Here are two screenshots. First from local version and second from hosted version.

I am on Mac OS X 10.14.5
I don't have any TZ related env variable set
I just have LANG=en_GB.UTF-8

$ date +%z
+0200

Note that I also tested on a Cloud9 machine running in Ireland (TZ=GMT) and it works correctly. Problems seems only with TZ > GMT

[sebsto]

I changed my Cloud9 machine's TZ (following instructions at https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html)

$ date 
Fri May 31 12:00:52 CEST 2019

$ date +%z
+0200

And can reproduce the problem.

So, it is pretty easy for you to reproduce, just spawn a Cloud9 or EC2 instance, change the timezone and voila ! :-)

[harrysolovay]

@sebsto this is extremely helpful. Will get back to you about this soon.

[sebsto]

I am trying to nail down the root cause, but I am new to Gatsby and I am slow on this :-)
Looks like the data returned the Gatsby GraphQL API is incorrect. So I think this is not a rendering issue as I initially supposed, but the root cause lies probably in the module (a Gatsby module?) that reads the Markdown and exposes it through GraphQL.

Here is my GraphQL query executed in GraphiQL :

fragment Contributor on MarkdownRemark {
    fields {
      key
      slug
    }
    frontmatter {
      name
      bio
      github
      twitter
      website
    }
  }
  
  fragment SharedBetweenPostsAndEvents on MarkdownRemark {
    fields {
      key
      slug
      date(formatString: "MMMM D, YYYY")
    }
    frontmatter {
      href
      title
      description
      tags
    }
  }

fragment Event on MarkdownRemark {
    ...SharedBetweenPostsAndEvents
    fields {
      attendants {
        ...Contributor
      }
    }
    frontmatter {
      city
      country
    }
  }
 
  query($currentDate: Date!) {
    allMarkdownRemark(
      sort: {fields: [fields___date], order: ASC}
      filter: {fields: {category: {eq: "events"}, date: {gt: $currentDate}}}
    ) {
      edges {
        node {
          ...Event
          frontmatter {
            platforms
          }
        }
      }
    }
  }

with

{ "currentDate": "2019-06-01" }

And here is a result extract :

{
          "node": {
            "fields": {
              "key": "uActwvwBgN5",
              "slug": "events/2019/06/11/devdays",
              "date": "June 10, 2019",
              "attendants": [
                {
                  "fields": {
                    "key": "2vIVgGdj121",
                    "slug": "contributors/sebastien-stormacq"
                  },
                  "frontmatter": {
                    "name": "Sébastien Stormacq",
                    "bio": "Technical Evangelist @ AWS France.  Talk about frontend, serverless and identity.  https://stormacq.com",
                    "github": "sebsto",
                    "twitter": "sebsto",
                    "website": null
                  }
                }
              ]
            }

As you can see :

"slug": "events/2019/06/11/devdays",
"date": "June 10, 2019",

The directory name is correctly parsed as 2019/06/11 but the date returned is 2019/06/10

[sebsto]

BTW, I don't think it is related, but most of the onCreateNode code is never executed because this condition is always false https://github.com/aws-amplify/community/blob/master/gatsby-node/onCreateNode.js#L13 It looks like the whole onCreateNode code is not used and can safely be removed from https://github.com/aws-amplify/community/blob/master/gatsby-node/constants.js#L4 without any visible effect on the rendering. Is this correct ?

But the date received here is already incorrect :

"context": {
    "slug": "events/2019/07/26/addc",
    "date": "2019-07-25T22:00:00.000Z"
  },

[harrysolovay]

@sebsto I don't believe so; node.internal.type === 'MarkdownRemark' is often true... can you please describe the problem another way?––I don't think I understand.

Also, in regards to the timezone problem, the solution would probably be to generate many builds for different time zones and feed them up depending on the client. This could be tough to implement. I can't find pre-existing conversations about this problem in Gatsby projects. Feels like a problem with the build paradigm itself. Any other ideas on how we might be able to solve this issue without doing anything at runtime?

[sebsto]

Regarding the date : Gatsby is returning an incorrect date. It takes the date from the slug : 2019-07-26) in this example. It considers the time as being 00:00am GMT. Then it applies the timezone conversion according to client's timezone (for me GMT+2) to calculate the GMT / Zulu time (so minus 2h in this example), which produce a date 2h before the previous day (2019-07-25 22:00 Zulu time)

"context": {
    "slug": "events/2019/07/26/addc",
    "date": "2019-07-25T22:00:00.000Z"
  },

When the build machine has a local TZ in GMT, the problem does not appear. This is why the public web site is correct.

I would suggest to modify the Gatsby module to not make that time conversion. But this is potentially a breaking change for other Gatsby apps.

I don't like the idea to generate multiple builds, for each different timezone (24 !) The design best practice is to store time in Zulu time and display in local time to the client app. TZ rendering should be a front end issue. Ideally, Gastby must return the GMT time and we should have client side code to convert it to local or not.

Regarding this use case, we can safely assume that event organisers are always going to give the date of their event / conference in local time and people interested to attend the conference are only interested by local time only. So if Gatsby returns whatever the event organiser entered, without conversion, we will be good.

[harrysolovay]

@sebsto good call & agreed. Thank you for the deep dive! Will fix this asap.