date: field, valid entries

[baptiste]

I'm finding problems when converting old documents from Rmd to qmd, in that I tend to use custom formats for the date, such as:

• date: "`r format(Sys.time(), '%d %B, %Y')`"
• date: "\\the\\year, Trimester 1"
• date: 2023
• date: !expr "`r format(Sys.time(), "%d %B, %Y")`" (or something like that, I can never remember/find the right syntax)

etc.

Quarto seems to perform some strict checks and either refuses to compile the document or, potentially worse, interprets the date as Y/M/D.

Most of the time I just end up changing date: with a custom variable such as taught: Trimester 1 and use the corresponding variable in the custom pandoc template, but if I was using a default template that workaround would not be possible. Is there a way to relax the checks for yaml entries? Or some flexible formatting options I might have overlooked? (common use-cases as shown above include specifying the year only, with a custom string attached, etc.)

[dragonstyle]

In Quarto, we do our best to separate the date value and the formatting of the date. So, the best way to approach this, I think, is to specify a date and date-format separately. For example, to display only the year, you could write something like:

---
title: Quarto Document
author: Norah Jones
date: 2022-10-13
date-format: YYYY
---

## Test

Lorem ipsum.

There are a few useful date macros that are treated specially (today, now, and last-modified).

More about specifying dates and date formats here:

https://quarto.org/docs/reference/dates.html

HTH!

[baptiste]

My (personal, 100% unofficial!) perspective for r foo() and !expr foo() in quarto metadata is: "this stuff will generally void your warranty and risk nasal demons". We can't stop downstream packages from more or less doing it, but if you use that stuff, we can't promise much ourselves, and as time goes by, it becomes more likely that it will break your .qmd files in a hard-to-detect way.

That's fair, and I think it would be worth adding a note along those lines in the docs, under a FAQ for former Rmd users/hackers kind of section.

That being said, I do think systems like Quarto will always hugely benefit from allowing custom syntax extensions (/ "hacks") that go beyond the original framework. I just came across typst, whose macro syntax reminds me a little of Pollen, and of course LaTeX macros, and pandoc template variables, etc. What I'm trying to say is: allowing "arbitrary hacks" into the system is a huge part of what makes these tools successful, because they let users implement almost arbitrary new ideas (the "make it easy to do easy things, possible to do hard things" adage), some of which might later prove sufficiently valuable & desirable to be properly implemented and supported.

My personal view is that it would be nice to have a generic pre-processor mechanism that produces a valid and vanilla .qmd file for quarto to process, from an input file with (almost arbitrary) custom syntax extensions (provided the transformer know what to do – and I think custom pandoc writers might be a good example of that, or Pollen, actually).

[mcanouil]

Based on the original post items.

From date: "`r format(Sys.time(), '%d %B, %Y')`"¹

date: today
date-format: DD MMMM, YYYY

Alternatively, there is an ugly way to do it with knitr:

---
title: "My document"
format: html
---

```{r}
#| results: asis
#| echo: false
cat(
  "---\n",
  "date: ", format(Sys.time(), "%d %B, %Y"), "\n",
  "---\n",
  sep = ""
)
```

From date: "\\the\\year, Trimester 1"

date: today
date-format: YYYY[, Trimester 1]

From date: 2023

date: today
date-format: YYYY

Footnotes

1. Apparently, the new !expr prefix does not seem to be supported for date in RMarkdown as well. ↩

[baptiste]

For short, @baptiste either embrace Quarto syntax or stick to RMarkdown 😅

I'm happily switching for most things (except when on a deadline, etc.), and I think it's fair to say that for many long-time users of knitr/Rmd (I've used it for over a decade) Quarto feels like it has learned and benefited from all the positive things that were developed in that ecosystem. But to me it also points to the huge benefit of having a flexible (hackable) system, not just to ensure that old hacks can still survive (that's not very important, as long as there is an equivalent, proper way to do things), but more importantly to develop new ideas.

[mcanouil]

I just posted flexible hackable solutions from the formats you highlighted in your post.

[cscheid]

@baptiste I hear you. For the deep hackers like you, quarto is currently at an awkward spot where not everything that should be hackable is. We appreciate your patience and I hope you believe me when I say that I was an emacs user for 25 years of my life for good reason, and making quarto fundamentally hackable is a central concern of mine (I can say that with 100% certainty for myself, and with 90% certainty for the other folks in the team :)).

The biggest challenge is how to make it both hackable and engine-agnostic. We're making progress, but there are a lot of parts where we could do better! We hope we can keep you deep hackers interested while we get everything ready <3