Yaml Frontmatter Date off by 1 day

[DavidWells]

Just noticed this on the serverless.com blog. Looks like the date from head data is shifting the date one day backwards.

This frontmatter:

---
date: 2016-12-15
---

In the Post layout head.date === 2016-12-15T00:00:00.000Z

When converting this to date new Date(head.date) it gives back Wed Dec 14 2016 16:00:00 GMT-0800 (PST) which is a day off

Is anyone else seeing this behavior?

This is the code printing out our date: https://github.com/serverless/site/blob/a1659dafc8ceffd3e5df5b14086eb63cffb90635/src/layouts/Post/index.js#L37-L46

I can fix this on my end with some math but it seems like a bug that might be effecting others.

This will shift the date to the correct 2016-12-15 date

console.log(new Date(pageDate.getTime() + Math.abs(pageDate.getTimezoneOffset() * 60000)))

Here is another example: https://serverless.com/blog/a-serverless-windclock-at-the-lake/ and the markdown https://github.com/serverless/blog/blob/master/posts/2017-01-17-a-serverless-windclock-at-the-lake.md (the date should be 2017-01-17 but it's not =P)

[DavidWells]

Live example links won't work. I fixed this in userland: https://github.com/serverless/site/commit/0a9bc4045b63997f7fef17ae4e96b53d414f344b but still think this might be a core issue

[MoOx]

How can it be a core issue? Date are strings, so it's impossible Phenomic can be responsible of this.
If I run this in my browser console

> const d = new Date("2016-12-15")
> d.toISOString()
< "2016-12-15T00:00:00.000Z"

I get a correct number.

I don't have this issue on others projects that use the same technique.

Even the default theme is not affected.

• https://github.com/MoOx/phenomic/blob/89ce2f8d803469a47bb450fd6e0b4f4d6d88c001/themes/phenomic-theme-base/content/posts/hello-world.md
• https://phenomic.io/themes/base/demo/posts/hello-world/

One thing that can be is maybe the machine building the site?

[thangngoc89]

I had this issue before, this is becuase of the different in timezone between the building machine, dev machine and user machine. I ended up not printing pretty day format

[DavidWells]

That could be it. Not sure where netlify build takes place.

Is there a way to set timezone in NODE.ENV or something? =)

[MoOx]

Anyway, client side should update this correctly, it can only be incorrect for static build. So if your JS is on, you should not get this bug.

[brianrc]

It's a JavaScript thing. I encountered it too with my event calendar and had to do something weird based on the suggestions here:
http://stackoverflow.com/questions/7556591/javascript-date-object-always-one-day-off

const pageDate = head.date ? new Date(head.date.replace(/-/g, '\/').replace(/T.+/, '')) : null

[DavidWells]

Yeah this is why I suggested fixing it in core. Users will encounter this over and over. The YAML date should be converted to YYYY/MM/DD (slashes with no T0000000) like Brian mentions.

…

On Jan 19, 2017, at 2:05 AM, Brian Cruikshank ***@***.***> wrote: It's a JavaScript thing. I encountered it too with my event calendar and had to do something weird based on the suggestions here: http://stackoverflow.com/questions/7556591/javascript-date-object-always-one-day-off const pageDate = head.date ? new Date(head.date.replace(/-/g, '\/').replace(/T.+/, '')) : null — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[thangngoc89]

@DavidWells youre suggesting we fix the language. Lol.

[MoOx]

Maybe we should fix this via #397?

[MoOx]

Otherwise we can assume it's a userland thing and recommend a given format in the doc.

[DavidWells]

Nah just auto format to the slashes and get rid of the ISO time stamp

The date should render correctly regardless of where the build happens. If I give a markdown file a time stamp, I'd expect it to render the correct date out for me.

Yes it's a JS and ISO issue but it can be easily fixed by making head.date return yyyy/mm/dd instead of the dashes

[MoOx]

I think the problem is that "YYYY-MM-DD" is probably considered as GMT00:00 by JS. So it will depend on your browser TZ. Pretty sure yyyy/mm/dd is considered as a local (non iso) date and is not likely going to be rendered the same depending on your TZ. We should try that on.

What gives this for you?

> const d = new Date("2016/02/02")
> d.toISOString()
< "2016-02-01T23:00:00.000Z"
> d.getTimezoneOffset()
< -60

Cause for me I see a one day diff! So this don't work for me :( (I am GMT+1)

[DavidWells]

This is harder than I thought. https://nulogy.com/who-we-are/company-blog/articles/dealing-with-timezones-in-javascript/

Javascript is fucked up. Let's rewrite phenomic in Go ¯_(ツ)_/¯

How do we get 2016-02-02 to always print out "February 2, 2016" always regardless of timezone? Do we need the moment.js lib?

[DavidWells]

I think UTC times might also address this issue

[thangngoc89]

@DavidWells dealing with date and time is fucking hard with Javascript, especially when it comes to server-side rendering. The output string would be different between the static HTML and client-rendered one. I have no solution for this really. :/

[montogeek]

moment.js

[DavidWells]

The problem with moment.js is that is it a very very large library and would add lots of weight to the bundles =(

[thangngoc89]

moment.js is a fat library. A quick search shows me this https://github.com/taylorhakes/fecha . 2KB

[montogeek]

There is another alternative: https://date-fns.org/

[brianrc]

What about globalize.js date module? It and moment.js are what react-big-calendar supports. Not that that means anything, just giving another option. :) Also supports relative time.

[MoOx]

Simple problem, simple solution

> (new Date("2016-01-01T00:00:00+00:00")).toISOString()
< "2016-01-01T00:00:00.000Z"

> (new Date("2016/01/01 00:00:00 +00:00")).toISOString()
< "2016-01-01T00:00:00.000Z"

const sortOfDate = "YYYY.MM.DD"

function dateify(date) {
  // if we have a valid date
  if (date.length === sortOfDate.length && !isNaN(Date.parse(date))) {
    // we try to adjust depending on the format
    switch (date[4]) {
      case "/": return new Date(date + " 00:00:00 +00:00")
      case "-": return new Date(date + "T00:00:00+00:00")
    }
  }
  
  return new Date(date)
}

> dateify("2016/01/01").toISOString()
< "2016-01-01T00:00:00.000Z"
> dateify("2016-01-01").toISOString()
< "2016-01-01T00:00:00.000Z"

Do you want a very tiny util available somewhere?

[DavidWells]

Add this to phenomic utils perhaps?

[MoOx]

See #999

[MoOx]

Closing as the solution should be enough.

[MoOx]

Oups not released yet.

[MoOx]

user land solution.