Dates work locally, but not when served with AWS

[smugclimber]

Using this code in one of my include files {{ page.last_modified_at | date: '%B %d, %Y' }} to show the user the last time the article was updated. The jekyll-last-modified-at plugin works like a charm locally and shows the file mod date in my page html. However, when I push it up to the AWS server, the live site marks every article with January 01, 1970.

Any ideas how to remedy this? Think it's a bug or part of my build setup?

Project Specs: Jekyll 3.8.5 Bundler 1.16.0 Gem 2.6.11 jekyll-last-modified-at 1.1.0

[EdenKupe]

I'm facing a similar issue on Platform.sh. Works well locally but all dates are the same on the live site, set to the last time any page was updated.

FYI - I've also encountered this issue with other Jekyll plugins so it might be a Jekyll issue instead of a specific one with this plugin.

[bronzdoc]

Facing the same issue on Heroku

[EdenKupe]

From what I've been told (sorry, I don't remember where), this is not a bug but a change in how Jekyll works. When you build the site now, Jekyll "touches" all files, essentially modifying them. Haven't been able to find a work-around to this so if anyone has one, let us know!

[lubc]

In case anyone is interested, here there's a tool to manage outdated articles in Jekyll: https://github.com/marketplace/outdated-article

[prenetic]

I know this is an old thread, but I'm running into the same issue on Cloudflare Pages. Locally the dates are rendered correctly (using them for my sitemap), but on Cloudflare it shows the fallback date for all entries, which is the publishing date.

There's a mention in the README.md about fallback value being derived from a file's mtime if the last Git commit date is inaccessible for some reason, so I'm wondering if that might have something to do with this.

[prenetic]

I reached out to the folks on the Cloudflare Developers Discord server, and a Cloudflare community member reached out and provided this information:

We checkout the commit (detached head) so there isn't a history. You could get that commits date but not any previous commits date.

[itay1313]

Hey, I'm having the same problem as well :) Anyone found a workaround for this?

[bewuethr]

I believe this happens when you do a shallow clone or checkout, like what the actions/checkout action does by default. As this plugin looks at the most recent Git commit, and there is only one, every last_modified_at timestamp is going to be equal to that last commit's time.

A workaround, for GitHub Actions, could be to use fetch-depth: 0 to fetch the entire history, but that can be slow.

Edit: actually, not too bad... my page has 388 commits, and the repo clocks in at about 193 MB; checkout isn't any slower with fetch-depth: 0. I guess it depends on your repo history, but if your diffs are mostly adding new things, I believe there isn't a big difference between shallow and deep clones.

[Mohamed3nan]

try to concatenating git fetch --unshallow && onto the build command

[VerzatileDev]

I believe this happens when you do a shallow clone or checkout, like what the actions/checkout action does by default. As this plugin looks at the most recent Git commit, and there is only one, every last_modified_at timestamp is going to be equal to that last commit's time.

A workaround, for GitHub Actions, could be to use fetch-depth: 0 to fetch the entire history, but that can be slow.

Edit: actually, not too bad... my page has 388 commits, and the repo clocks in at about 193 MB; checkout isn't any slower with fetch-depth: 0. I guess it depends on your repo history, but if your diffs are mostly adding new things, I believe there isn't a big difference between shallow and deep clones.

Thank you for the work around, Did not even think of using "fetch-depth" to be quite honest, saved me another hour of headache.

[omarcostahamido]

@VerzatileDev @bewuethr I reckon you add that line in the .github/workflows/jekyll.yml file, correct? Where exactly do you add it? is it like this?

jobs:
  # Build job
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

[VerzatileDev]

@VerzatileDev @bewuethr I reckon you add that line in the .github/workflows/jekyll.yml file, correct? Where exactly do you add it? is it like this?

jobs:
  # Build job
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

@omarcostahamido I forgot how I did it all, but seeing my pull requests and issue as the following: https://github.com/VerzatileDevOrg/Programming_HandBook/issues/40 and https://github.com/VerzatileDevOrg/Programming_HandBook/pull/51 might be a good place to start.

fetch-depth: 0 should be what gets the entire history or the repository, so that would be for every commit made in it, from that this is where the " Last Modified " comes in. You can then follow my comments and resources there

Good luck!

[bewuethr]

@VerzatileDev @bewuethr I reckon you add that line in the .github/workflows/jekyll.yml file, correct? Where exactly do you add it? is it like this?

jobs:
  # Build job
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

You have to do the deep clone in the same job as the jekyll build step. Here's how I do it for a Jekyll website that I maintain:

jobs:
  build:
    name: Build page
    runs-on: ubuntu-22.04
    permissions:
      contents: read
    env:
      RUBY_YJIT_ENABLE: 1
    steps:
      - name: Check out repo
        uses: actions/checkout@v4.1.2
        with:
          fetch-depth: 0

      - name: Setup Ruby
        # yamllint disable-line rule:line-length
        uses: ruby/setup-ruby@d4526a55538b775af234ba4af27118ed6f8f6677  # v1.172.0
        with:
          rubygems: 3.5.6
          bundler-cache: true

      - name: Build with Jekyll
        env:
          JEKYLL_ENV: production
        run: bundle exec jekyll build --verbose --baseurl ''

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3.0.1

[ldemailly]

if anyone is interested, this made it finally work: https://github.com/ldemailly/laurentsv/blob/master/.github/workflows/jekyll-gh-pages.yml