Let's say you build a blog with Gatsby where each article is written in markdown and queried from your local filesystem with GraphQL with the help of the plugin gatsby-source-filesystem.
Now you also want to show the date of when the article was created.
So you go to Gatsby's interactive GraphQL interface (see below) and search for a field name that looks like it's a date. You find birthTime. Sounds great! The intuition here is that the article creation date is identical to the date when the file was first created on a hard drive/file system, which is what birthTime signifies.
So you query this field and it gives you some dates that look about right. Then you render them in your frontend and everything looks great on the development server. Even when do a real build on your local machine (gatsby build & gatsby serve).
The surprise comes when you involve CI/CD. Let's say you deploy with Netlify. Once your site is build by Netlify based on your Git repository, you will see different dates - namely: The time it is right now!
Why is that? Remember that we said earlier that birthTime is referring to the date when the file was first created on a hard drive/file system. Now, if you have a CI/CD service like Netlify building your site, it first fetches your repository from Github and creates all those files again on its own filesystem. Those are entirely new files! That's why their birthTime is different.
So how can you add a creation date to your blog entries?
- Hardcode a date string into the frontmatter of your markdown files
- Use a CMS (like Netlify CMS) that offers a UI for these things, or adds dates to the data layer automatically
Just like @pentacular said: "If it's a meaningful part of the file content, it better be part of the file content."
Top comments (5)
File creation time should never be used for anything other than relative staleness checks.
If it's a meaningful part of the file content, it had better be part of the file content. :)
Just curious: What do you consider a 'staleness check'? (when would you do that)? Thanks!
Let's say that one file is produced from another.
It is never incorrect to regenerate it, but unnecessary unless the other file has since been modified.
Or say that the file is sufficiently up to date not to regenerate if it was modified less than some time ago.
I see, thanks!
You're absolutely right! I updated this posts title to account for this more general truth. Your comment can stay how it is, it still makes sense :-D