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

[jules32]

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!

[cderv]

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()

[jules32]

Thanks @cderv.

Yes, I'm on a Mac OS Catalina 10.15.5.

> Sys.timezone()
[1] "America/Los_Angeles"

[jjallaire]

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 < ***@***.***> 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 <#315 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAZPR6ZUW2TLP6U4E4SEWDS6VFGPANCNFSM4XPOMF2Q> .

[cderv]

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.

[jules32]

This is from Firefox > Inspect Element > Console:

test = new Date("2021-01-28T00:00:00.000+00:00")
test
Date Wed Jan 27 2021 16:00:00 GMT-0800 (Pacific Standard Time)

[cderv]

So this confirms the difference in date, you see 'date - 1' because the HTML content was produced on a system running OSX so a date in with ISO 8601 using UTC as timezone (of the form "%Y-%m-%dT%H:%M:%S%z").
Javascript will parse this date and convert to your local timezone.

We know the why now. Bad news is that the underlying issue seems not fixed yet: tidyverse/lubridate#928

[cderv]

@jules32 the initial issue in distill was #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.

[jules32]

Thanks for digging into this more Christophe, J.J. et al.

With Mac OS Catalina 10.15.5, R 4.0.3, just installed lubridate from CRAN:

> tz <- Sys.timezone()
> tz <- ifelse(is.na(tz), "UTC", tz)
> lubridate::mdy("12/22/22", tz = tz, quiet = TRUE)
[1] "2022-12-22 PST"

[cderv]

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

[cderv]

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

[jules32]

Thank you!

I've just tried it, but unfortunately had the following error:

install.packages("lubridate")
devtools::install_github("rstudio/distill")

==> rmarkdown::render_site(encoding = 'UTF-8')

Error in C_force_tz(time, tz = tzone, roll) : 
  CCTZ: Unrecognized output timezone: "America/Los_Angeles"
Calls: <Anonymous> ... .parse_date_time -> .strptime -> force_tz -> C_force_tz
Execution halted

Exited with status 1.

[cderv]

🤔 lubridate should have been updated and the error should be fine as your test above #315 (comment).

It is like lubridate issue is still there.

I'll have a closer look.

[jthomasmock]

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.

[cderv]

Thanks @jthomasmock ! This would confirm that the fix in lubridate is ok. And so that distill can safely depends on new CRAN version to fix this issue.

However, I can't explain why it does not work for you @jules32. Can you retry in a clean R session to confirm ?

Thank you.

[jules32]

Hmm. Unfortunately the same errors persist when I start a clean R session. I tried this on 3 IDE versions:

• RStudio v1.4.1100
• RStudio v1.4.1106-4 Preview
• RStudio v1.4.1103

Not sure if this is relevant so apologies if it's not: when I install distill I get an error when saying "Yes" to installing mime with compilation (below shows that error. I have been then saying "No" to complete the installation)

devtools::install_github("rstudio/distill")
Downloading GitHub repo rstudio/distill@HEAD
These packages have more recent versions available.
It is recommended to update all of them.
Which would you like to update?

1: All                      
2: CRAN packages only       
3: None                     
4: mime (0.9 -> 0.10) [CRAN]

Enter one or more numbers, or an empty line to skip updates:1
mime (0.9 -> 0.10) [CRAN]
Installing 1 packages: mime

  There is a binary version available but the source version is later:
     binary source needs_compilation
mime    0.9   0.10              TRUE

Do you want to install from sources the package which needs compilation? (Yes/no/cancel) Yes
installing the source package ‘mime’

trying URL 'https://cran.rstudio.com/src/contrib/mime_0.10.tar.gz'
Content type 'application/x-gzip' length 13047 bytes (12 KB)
==================================================
downloaded 12 KB

* installing *source* package ‘mime’ ...
** package ‘mime’ successfully unpacked and MD5 sums checked
** using staged installation
** libs
xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun
ERROR: compilation failed for package ‘mime’
* removing ‘/Library/Frameworks/R.framework/Versions/4.0/Resources/library/mime’
* restoring previous ‘/Library/Frameworks/R.framework/Versions/4.0/Resources/library/mime’
Error: Failed to install 'distill' from GitHub:
  (converted from warning) installation of package ‘mime’ had non-zero exit status

[cderv]

mime has been updated to CRAN recently and the binary is not yet available for Mac OS. And it seems you are missing the development tools to install the source version. (about that if you want to setup, see https://r-pkgs.org/setup.html#macos)

The previous mime version is ok - this should not be related to an issue in distill.

Thanks for trying again. This means that there is still an issue with CRAN lubridate.

Can you run other commands for me ?

distill:::parse_date("12-22-2021")

Also can you run the rmarkdown::render_site() in R console to see what the traceback is when you get the error ?

Thank you.

[jules32]

Thanks Christophe.

distill:::parse_date("12-22-2021")
Error in C_force_tz(time, tz = tzone, roll) : 
  CCTZ: Unrecognized output timezone: "America/Los_Angeles"

and:

rmarkdown::render_site()
Error in C_force_tz(time, tz = tzone, roll) : 
  CCTZ: Unrecognized output timezone: "America/Los_Angeles"
> traceback()
19: stop(structure(list(message = "CCTZ: Unrecognized output timezone: \"America/Los_Angeles\"", 
        call = C_force_tz(time, tz = tzone, roll), cppstack = structure(list(
            file = "", line = -1L, stack = c("1   lubridate.so                        0x000000010eea3dde _ZN4Rcpp9exceptionC2EPKcb + 222", 
            "2   lubridate.so                        0x000000010eea7b2e _ZN4Rcpp4stopIJRNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEEEEEvPKcDpOT_ + 78", 
            "3   lubridate.so                        0x000000010eea7abe _Z15load_tz_or_failNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEERN4cctz9time_zoneES5_ + 110", 
            "4   lubridate.so                        0x000000010eea9043 _Z10C_force_tzN4Rcpp6VectorILi14ENS_15PreserveStorageEEENS0_ILi16ES1_EEb + 771", 
            "5   lubridate.so                        0x000000010ee9f36d _lubridate_C_force_tz + 189", 
            "6   libR.dylib                          0x000000010af5f642 R_doDotCall + 1458", 
            "7   libR.dylib                          0x000000010afab51a bcEval + 105338", 
            "8   libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "9   libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "10  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "11  libR.dylib                          0x000000010af98448 bcEval + 27304", 
            "12  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "13  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "14  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "15  libR.dylib                          0x000000010af98448 bcEval + 27304", 
            "16  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "17  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "18  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "19  libR.dylib                          0x000000010af98448 bcEval + 27304", 
            "20  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "21  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "22  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "23  libR.dylib                          0x000000010af98448 bcEval + 27304", 
            "24  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "25  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "26  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "27  libR.dylib                          0x000000010af98448 bcEval + 27304", 
            "28  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "29  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "30  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "31  libR.dylib                          0x000000010af98448 bcEval + 27304", 
            "32  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "33  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "34  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "35  libR.dylib                          0x000000010af98448 bcEval + 27304", 
            "36  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "37  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "38  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "39  libR.dylib                          0x000000010af98448 bcEval + 27304", 
            "40  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "41  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "42  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "43  libR.dylib                          0x000000010af98448 bcEval + 27304", 
            "44  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "45  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "46  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "47  libR.dylib                          0x000000010af98448 bcEval + 27304", 
            "48  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "49  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "50  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "51  libR.dylib                          0x000000010af98448 bcEval + 27304", 
            "52  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "53  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "54  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "55  libR.dylib                          0x000000010af98448 bcEval + 27304", 
            "56  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "57  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "58  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "59  libR.dylib                          0x000000010af98448 bcEval + 27304", 
            "60  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "61  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "62  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "63  libR.dylib                          0x000000010afb2429 R_forceAndCall + 841", 
            "64  libR.dylib                          0x000000010aeeeb95 do_lapply + 901", 
            "65  libR.dylib                          0x000000010aff8d7d do_internal + 365", 
            "66  libR.dylib                          0x000000010af98d6d bcEval + 29645", 
            "67  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "68  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "69  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "70  libR.dylib                          0x000000010af98448 bcEval + 27304", 
            "71  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "72  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "73  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "74  libR.dylib                          0x000000010af98448 bcEval + 27304", 
            "75  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "76  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "77  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "78  libR.dylib                          0x000000010af98448 bcEval + 27304", 
            "79  libR.dylib                          0x000000010af91261 Rf_eval + 385", 
            "80  libR.dylib                          0x000000010afb1791 R_execClosure + 2193", 
            "81  libR.dylib                          0x000000010afb0569 Rf_applyClosure + 473", 
            "82  libR.dylib                          0x000000010af91736 Rf_eval + 1622", 
            "83  libR.dylib                          0x000000010afe6cea Rf_ReplIteration + 810", 
            "84  libR.dylib                          0x000000010afe820f run_Rmainloop + 207", 
            "85  rsession                            0x000000010aa6be90 _ZN13rstudio_boost4asio6detail24descriptor_write_op_baseINS0_15const_buffers_1EE10do_performEPNS1_10reactor_opE + 666720", 
            "86  rsession                            0x000000010aa41779 _ZN13rstudio_boost4asio6detail24descriptor_write_op_baseINS0_15const_buffers_1EE10do_performEPNS1_10reactor_opE + 492873", 
            "87  rsession                            0x000000010a1cd238 _ZN13rstudio_boost4asio6detail30reactive_socket_accept_op_baseINS0_12basic_socketINS0_2ip3tcpEEES5_E10do_performEPNS1_10reactor_opE + 568504", 
            "88  libdyld.dylib                       0x00007fff6781bcc9 start + 1", 
            "89  ???                                 0x000000000000000b 0x0 + 11"
            )), class = "Rcpp_stack_trace")), class = c("Rcpp::exception", 
    "C++Error", "error", "condition")))
18: C_force_tz(time, tz = tzone, roll)
17: force_tz(out, tzone = tz)
16: .strptime(x, formats[[1]], tz = tz, quiet = quiet, locale = locale)
15: .parse_date_time(x, formats, tz = tz, quiet = quiet, locale = locale)
14: .local_parse(x[to_parse], TRUE)
13: parse_date_time(dates, orders, quiet = quiet, tz = tz, locale = locale, 
        truncated = truncated)
12: .parse_xxx(..., orders = "ymd", quiet = quiet, tz = tz, locale = locale, 
        truncated = truncated)
11: lubridate::ymd(date, tz = safe_timezone(), quiet = TRUE)
10: parse_date(date)
9: resolve_date(article_dir, metadata$date)
8: transform_metadata(article$path, site_config, collection, article$metadata, 
       auto_preview = TRUE)
7: published_article_from_dir(site_config, collection, article_dir)
6: enumerate_collection(site_dir, site_config, collection)
5: FUN(X[[i]], ...)
4: lapply(site_collections, function(collection) {
       enumerate_collection(site_dir, site_config, collection)
   })
3: enumerate_collections(input, config, site_collections)
2: generator$render(input_file = input_file, output_format = output_format, 
       envir = envir, quiet = quiet)
1: rmarkdown::render_site()

[cderv]

Thanks.
It seems the issue with lubridate is still there for you

What I don't understand is why this worked for you before in #315 (comment)

In distill we got

> packageVersion("distill")
[1] ‘1.2.1’

a parsing function

> distill:::parse_date
function (date) 
{
    if (!is.null(date)) {
        parsed_date <- lubridate::mdy(date, tz = safe_timezone(), 
            quiet = TRUE)
        if (is.na(parsed_date)) 
            parsed_date <- lubridate::ymd(date, tz = safe_timezone(), 
                quiet = TRUE)
        if (lubridate::is.POSIXct(parsed_date)) 
            date <- parsed_date
    }
    date
}

with timezone set with

> distill:::safe_timezone
function () 
{
    tz <- Sys.timezone()
    ifelse(is.na(tz), "UTC", tz)
}

So distill:::parse_date("12-22-2021") is equivalent to

packageVersion("lubridate") # 1.7.9.2
tz <- Sys.timezone()
tz <- ifelse(is.na(tz), "UTC", tz)
lubridate::mdy("12-22-2021", tz = tz, quiet = TRUE)
lubridate::ymd("12-22-2021", tz = tz, quiet = TRUE)

even simpler

lubridate::mdy("12-22-2021", tz = "America/Los_Angeles", quiet = TRUE)
lubridate::ymd("2021-12-22", tz = "America/Los_Angeles", quiet = TRUE)

So this code should error for you, but it isn't in in #315 (comment)

From your traceback(), the issue is still in lubridate. If you confirm this with the code above, I should revert the fix and we should report back to tidyverse/lubridate#928 to say it is not fixed.

Thanks for your patience with this. Without being able to reproduce on my side, it is hard for me to look into myself.

[cderv]

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: tidyverse/lubridate@6c535c8
• 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]

Reverted for now in 89d0b00

[jules32]

Thanks Christophe, I appreciate all your work on this. Please let me know if I can help test more moving forward!

[cderv]

@jules32 a new version of lubridate has been release to CRAN. This should solves our issue here definitly.
Can you try #326 branch and confirms this works correctly for you before I merged ?

remotes::install_github("rstudio/distill#326")
packageVersion("lubridate") # should be 1.7.10

Thank you.

[jules32]

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.

[cderv]

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