distill: Built blog posts display incorrect date (date-1) compared to slug and listing page

Hi All,

I’m creating this issue following a thread on community.rstudio.com with @cderv and @jthomasmock. Please let me know if I can help test anything or provide feedback otherwise! Thanks so much.

I’m seeing strange behavior where a built distill post displays the incorrect date compared to the url slug and the listing page. An example (github repo, published site):

I also see this when browsing other people’s published distill blogs, including those linked from https://pkgs.rstudio.com/distill/articles/examples.html, for example, https://blogs.rstudio.com/ai/posts/2021-02-11-tabnet/:

@cderv suspects that this is a timezone issue, because in France he sees the dates represented correctly. He says (I believe this is the url for “the code source”):

The code source of your page contains :

<script id="distill-front-matter" type="text/json">
{"title":"Interview with Dr. Dawn Wright","description":"Interview with Dr. Dawn Wright at MozFest","authors":[{"author":"Julie Lowndes & Erin Robinson","authorURL":"#","affiliation":"&nbsp;","affiliationURL":"#","orcidID":""}],"publishedDate":"2021-03-08T00:00:00.000+00:00","citationText":"Robinson, 2021"}
</script>

Which is the data process by the JS from distill library. As you see the date contains the timezone part. So for me translated in CET it not the same day as for you I think.

@jthomasmock was also able to reproduce this behavior locally and created a gif showing that:

when changing the date of a post it will correctly adjust the “slug” but will do the date - 1 for the actual displayed date for the article.

link to gif

Thanks for your help!

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 24 (1 by maintainers)

Commits related to this issue

yayyyy testing https://github.com/rstudio/distill/issues/315#issuecomment-787798224 — committed to Openscapes/events by jules32 3 years ago

Most upvoted comments

Awesome. This is merged now. So you can use Dev distill for this.

cderv on Mar 1, 2021

Hi @cderv – yes the issue is fixed for me now 🎉! It works locally as well as when published online.

Thank you so much, I really appreciate it. Distill is so awesome.

jules32 on Mar 1, 2021

It seems there is something off with lubridate that makes thing goes crazy here:

CRAN says it is version 1.7.9.2 published on 13-11-2020: https://cran.r-project.org/web/packages/lubridate/index.html
NEWS says the issue mentioned here is fixed: https://cran.r-project.org/web/packages/lubridate/news/news.html
But the last commit that fixed the issue is from the 21-11-2020: https://github.com/tidyverse/lubridate/commit/6c535c82ed7f263ce5daceba9c87827400d4423e
On github the commit says it is included in the release tag 1.7.9.2 but it seems it is not. When I look at the code from the package I got install from CRAN, I don’t see the fix as the commit above.

Details

> packageVersion("lubridate")
[1] ‘1.7.9.2’
> lubridate:::.onLoad
function (libname, pkgname) 
{
    .find_tzdir <- function() {
        Sys.timezone()
        if (.Platform$OS.type == "windows") 
            return(file.path(R.home("share"), "zoneinfo"))
        tzdirs <- c("/usr/share/zoneinfo", "/usr/share/lib/zoneinfo", 
            "/usr/lib/zoneinfo", "/usr/local/etc/zoneinfo", 
            "/etc/zoneinfo", "/usr/etc/zoneinfo", 
            "/usr/share/zoneinfo.default", "/var/db/timezone/zoneinfo", 
            file.path(R.home("share"), "zoneinfo"))
        tzdirs <- tzdirs[file.exists(tzdirs)]
        if (length(tzdirs)) 
            tzdirs[[1]]
        else NULL
    }
    tzdir <- Sys.getenv("TZDIR")
    if (tzdir == "internal") {
        Sys.setenv(TZDIR = file.path(R.home("share"), "zoneinfo"))
    }
    else if (tzdir == "macOS") {
        if (!is.null(dir <- .find_tzdir())) 
            Sys.setenv(TZDIR = dir)
    }
    else if (tzdir == "") {
        if (!file.exists("/usr/share/zoneinfo")) {
            if (!is.null(dir <- .find_tzdir())) 
                Sys.setenv(TZDIR = dir)
        }
    }
    on_package_load("vctrs", {
        register_s3_method("vctrs", "vec_proxy", 
            "Period")
        register_s3_method("vctrs", "vec_proxy_compare", 
            "Period")
        register_s3_method("vctrs", "vec_proxy_equal", 
            "Period")
        register_s3_method("vctrs", "vec_restore", 
            "Period")
        register_s3_method("vctrs", "vec_ptype2", 
            "Period.Period")
        register_s3_method("vctrs", "vec_cast", "Period.Period")
        register_s3_method("vctrs", "vec_proxy", 
            "Duration")
        register_s3_method("vctrs", "vec_proxy_compare", 
            "Duration")
        register_s3_method("vctrs", "vec_proxy_equal", 
            "Duration")
        register_s3_method("vctrs", "vec_restore", 
            "Duration")
        register_s3_method("vctrs", "vec_ptype2", 
            "Duration.Duration")
        register_s3_method("vctrs", "vec_ptype2", 
            "Duration.difftime")
        register_s3_method("vctrs", "vec_ptype2", 
            "difftime.Duration")
        register_s3_method("vctrs", "vec_cast", "Duration.Duration")
        register_s3_method("vctrs", "vec_cast", "Duration.difftime")
        register_s3_method("vctrs", "vec_cast", "difftime.Duration")
        register_s3_method("vctrs", "vec_proxy", 
            "Interval")
        register_s3_method("vctrs", "vec_proxy_compare", 
            "Interval")
        register_s3_method("vctrs", "vec_proxy_equal", 
            "Interval")
        register_s3_method("vctrs", "vec_restore", 
            "Interval")
        register_s3_method("vctrs", "vec_ptype2", 
            "Interval.Interval")
        register_s3_method("vctrs", "vec_cast", "Interval.Interval")
    })
}
<bytecode: 0x0000021cc4d63030>
<environment: namespace:lubridate>

That is the only reason I see why this would not work. So I’ll revert and we still need to wait for a CRAN release of lubridate for this issue fixed. Thanks again @jules32

cderv on Feb 15, 2021

I’m getting the correct expected behavior now on a reprex-blog! Date indicated in the YAML gives the correct date in the blog-post description.

jthomasmock on Feb 14, 2021

🤔 lubridate should have been updated and the error should be fine as your test above https://github.com/rstudio/distill/issues/315#issuecomment-778336323.

It is like lubridate issue is still there.

I’ll have a closer look.

cderv on Feb 13, 2021

You can now use dev version of distill and rebuild your posts.

cderv on Feb 12, 2021

So it means this is fixed. We can now revert the fix and depend on new lubridate. Will push a fix soon.

cderv on Feb 12, 2021

@jules32 the initial issue in distill was https://github.com/rstudio/distill/issues/207 It seems the underlying issue is fixed in last lubridate (https://github.com/tidyverse/lubridate/blob/master/NEWS.md#version-1792)

Can someone on Mac with R 4.0.3 and last CRAN lubridate version can try

tz <- Sys.timezone()
tz <- ifelse(is.na(tz), "UTC", tz)
lubridate::mdy("12/22/22", tz = tz, quiet = TRUE)

Thanks.

cderv on Feb 12, 2021

Yes this is the exact issue I found in the investigation.

Date will be set to UTC timezone in the document. Example: "2021-01-28T00:00:00.000+00:00"
The date will be processed in your browser with JS, using your local timezone in your browser: Try in browser console:

test = new Date("2021-01-28T00:00:00.000+00:00")
test

That is why we don’t have the same date you and me, because I am GMT+1 and you’re not.

So this current fix cause every blogpost to show a wrong date when the UTC date is processed by JS distill script.

cderv on Feb 12, 2021

We had to put in a fix to workaround timezone issues in OS X / R 4.0.3. The fix was to force timezone to UTC, so this could indeed explain it. We expect to remove this fix once the underlying issues are addressed.

On Fri, Feb 12, 2021 at 10:53 AM Christophe Dervieux < notifications@github.com> wrote:

Hi,

I can’t reproduce the issue locally on my side but I may have found the cause. It is indeed with timezone and that is why it is hard for me to reproduce maybe.

A few question to confirm:

Are you on Mac OS ?

Which is your timezone ? Sys.timezone()

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rstudio/distill/issues/315#issuecomment-778276736, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAZPR6ZUW2TLP6U4E4SEWDS6VFGPANCNFSM4XPOMF2Q .

jjallaire on Feb 12, 2021