docs: fix %-d example in date specifier table

[prql-bot]

The %-d row in the date-specifier table shows its example as ` 8` — space-padded — but %-d maps to Item::Numeric(Numeric::Day, Pad::None) in prqlc/prqlc/src/sql/dialect.rs, i.e. no padding at all. Space-padding is what %k (and chrono's %_d) does, and the table already documents %k separately as "space-padded". The neighbouring %-m row correctly shows 7 with no leading space.

Docs-only, so there's no test to add. Found during the nightly survey of web/book/src/reference/stdlib/date.md.

[prql-bot]

Verified the change by compiling against the Postgres dialect: date.to_text "%-d" emits TO_CHAR(d, 'FMDD'), and the FM prefix suppresses padding entirely — so 8 is the right example and the previous 8 was wrong.

One adjacent thing the same table gets wrong, outside this diff and left for a separate decision: the %k row (Same as %H but space-padded. Same as %_H.) is listed under "specifiers currently supported", but prqlc rejects it. chrono parses %k as Item::Numeric(Numeric::Hour, Pad::Space), and no dialect's translate_chrono_item in prqlc/prqlc/src/sql/dialect.rs has a Pad::Space arm — every one falls through to the unsupported-specifier error. Confirmed by running it: select { a = (d | date.to_text "%k") } fails with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql. Whether the fix is to drop the row or to add space-padding support to the dialect handlers needs a maintainer call, so it's not folded in here.

Sweep of every specifier in the table against `sql.postgres`

%k is the only failing row; the other 27 all compile:

%Y TO_CHAR(d, 'YYYY') %H TO_CHAR(d, 'HH24')
%y TO_CHAR(d, 'YY') %k ERROR — unsupported
%m TO_CHAR(d, 'MM') %I TO_CHAR(d, 'HH12')
%-m TO_CHAR(d, 'FMMM') %p TO_CHAR(d, 'AM')
%b TO_CHAR(d, 'Mon') %M TO_CHAR(d, 'MI')
%B TO_CHAR(d, 'FMMonth') %S TO_CHAR(d, 'SS')
%d TO_CHAR(d, 'DD') %f TO_CHAR(d, 'US')
%-d TO_CHAR(d, 'FMDD') %R TO_CHAR(d, 'HH24:MI')
%a TO_CHAR(d, 'Dy') %T TO_CHAR(d, 'HH24:MI:SS')
%A TO_CHAR(d, 'FMDay') %X TO_CHAR(d, 'HH24:MI:SS')
%D TO_CHAR(d, 'MM/DD/YY') %r TO_CHAR(d, 'HH12:MI:SS AM')
%x TO_CHAR(d, 'MM/DD/YY') %+ TO_CHAR(d, 'YYYY-MM-DD"T"HH24:MI:SS.USZ')
%F TO_CHAR(d, 'YYYY-MM-DD') %t %n %% literals

[prql-bot]

Reproduced the %k finding and filed it as #6139 so it isn't lost when this merges — date.to_text "%k" errors with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql, because no dialect's translate_chrono_item has a Pad::Space arm. The issue lays out both resolutions (drop the row vs. implement space-padding, which needs LPAD rather than a format string on Postgres) plus a related gap: %-H works but isn't in the table, even though %-m and %-d are.

Keeping this PR to the one-line %-d correction.

[prql-bot]

The %-d row in the date-specifier table shows its example as ` 8` — space-padded — but %-d maps to Item::Numeric(Numeric::Day, Pad::None) in prqlc/prqlc/src/sql/dialect.rs, i.e. no padding at all. Space-padding is what %k (and chrono's %_d) does, and the table already documents %k separately as "space-padded". The neighbouring %-m row correctly shows 7 with no leading space.

Docs-only, so there's no test to add. Found during the nightly survey of web/book/src/reference/stdlib/date.md.

[prql-bot]

Verified the change by compiling against the Postgres dialect: date.to_text "%-d" emits TO_CHAR(d, 'FMDD'), and the FM prefix suppresses padding entirely — so 8 is the right example and the previous 8 was wrong.

One adjacent thing the same table gets wrong, outside this diff and left for a separate decision: the %k row (Same as %H but space-padded. Same as %_H.) is listed under "specifiers currently supported", but prqlc rejects it. chrono parses %k as Item::Numeric(Numeric::Hour, Pad::Space), and no dialect's translate_chrono_item in prqlc/prqlc/src/sql/dialect.rs has a Pad::Space arm — every one falls through to the unsupported-specifier error. Confirmed by running it: select { a = (d | date.to_text "%k") } fails with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql. Whether the fix is to drop the row or to add space-padding support to the dialect handlers needs a maintainer call, so it's not folded in here.

Sweep of every specifier in the table against `sql.postgres`

%k is the only failing row; the other 27 all compile:

%Y TO_CHAR(d, 'YYYY') %H TO_CHAR(d, 'HH24')
%y TO_CHAR(d, 'YY') %k ERROR — unsupported
%m TO_CHAR(d, 'MM') %I TO_CHAR(d, 'HH12')
%-m TO_CHAR(d, 'FMMM') %p TO_CHAR(d, 'AM')
%b TO_CHAR(d, 'Mon') %M TO_CHAR(d, 'MI')
%B TO_CHAR(d, 'FMMonth') %S TO_CHAR(d, 'SS')
%d TO_CHAR(d, 'DD') %f TO_CHAR(d, 'US')
%-d TO_CHAR(d, 'FMDD') %R TO_CHAR(d, 'HH24:MI')
%a TO_CHAR(d, 'Dy') %T TO_CHAR(d, 'HH24:MI:SS')
%A TO_CHAR(d, 'FMDay') %X TO_CHAR(d, 'HH24:MI:SS')
%D TO_CHAR(d, 'MM/DD/YY') %r TO_CHAR(d, 'HH12:MI:SS AM')
%x TO_CHAR(d, 'MM/DD/YY') %+ TO_CHAR(d, 'YYYY-MM-DD"T"HH24:MI:SS.USZ')
%F TO_CHAR(d, 'YYYY-MM-DD') %t %n %% literals

[prql-bot]

Reproduced the %k finding and filed it as #6139 so it isn't lost when this merges — date.to_text "%k" errors with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql, because no dialect's translate_chrono_item has a Pad::Space arm. The issue lays out both resolutions (drop the row vs. implement space-padding, which needs LPAD rather than a format string on Postgres) plus a related gap: %-H works but isn't in the table, even though %-m and %-d are.

Keeping this PR to the one-line %-d correction.

[prql-bot]

The %-d row in the date-specifier table shows its example as ` 8` — space-padded — but %-d maps to Item::Numeric(Numeric::Day, Pad::None) in prqlc/prqlc/src/sql/dialect.rs, i.e. no padding at all. Space-padding is what %k (and chrono's %_d) does, and the table already documents %k separately as "space-padded". The neighbouring %-m row correctly shows 7 with no leading space.

Docs-only, so there's no test to add. Found during the nightly survey of web/book/src/reference/stdlib/date.md.

[prql-bot]

Verified the change by compiling against the Postgres dialect: date.to_text "%-d" emits TO_CHAR(d, 'FMDD'), and the FM prefix suppresses padding entirely — so 8 is the right example and the previous 8 was wrong.

One adjacent thing the same table gets wrong, outside this diff and left for a separate decision: the %k row (Same as %H but space-padded. Same as %_H.) is listed under "specifiers currently supported", but prqlc rejects it. chrono parses %k as Item::Numeric(Numeric::Hour, Pad::Space), and no dialect's translate_chrono_item in prqlc/prqlc/src/sql/dialect.rs has a Pad::Space arm — every one falls through to the unsupported-specifier error. Confirmed by running it: select { a = (d | date.to_text "%k") } fails with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql. Whether the fix is to drop the row or to add space-padding support to the dialect handlers needs a maintainer call, so it's not folded in here.

Sweep of every specifier in the table against `sql.postgres`

%k is the only failing row; the other 27 all compile:

%Y TO_CHAR(d, 'YYYY') %H TO_CHAR(d, 'HH24')
%y TO_CHAR(d, 'YY') %k ERROR — unsupported
%m TO_CHAR(d, 'MM') %I TO_CHAR(d, 'HH12')
%-m TO_CHAR(d, 'FMMM') %p TO_CHAR(d, 'AM')
%b TO_CHAR(d, 'Mon') %M TO_CHAR(d, 'MI')
%B TO_CHAR(d, 'FMMonth') %S TO_CHAR(d, 'SS')
%d TO_CHAR(d, 'DD') %f TO_CHAR(d, 'US')
%-d TO_CHAR(d, 'FMDD') %R TO_CHAR(d, 'HH24:MI')
%a TO_CHAR(d, 'Dy') %T TO_CHAR(d, 'HH24:MI:SS')
%A TO_CHAR(d, 'FMDay') %X TO_CHAR(d, 'HH24:MI:SS')
%D TO_CHAR(d, 'MM/DD/YY') %r TO_CHAR(d, 'HH12:MI:SS AM')
%x TO_CHAR(d, 'MM/DD/YY') %+ TO_CHAR(d, 'YYYY-MM-DD"T"HH24:MI:SS.USZ')
%F TO_CHAR(d, 'YYYY-MM-DD') %t %n %% literals

[prql-bot]

Reproduced the %k finding and filed it as #6139 so it isn't lost when this merges — date.to_text "%k" errors with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql, because no dialect's translate_chrono_item has a Pad::Space arm. The issue lays out both resolutions (drop the row vs. implement space-padding, which needs LPAD rather than a format string on Postgres) plus a related gap: %-H works but isn't in the table, even though %-m and %-d are.

Keeping this PR to the one-line %-d correction.

[prql-bot]

The %-d row in the date-specifier table shows its example as ` 8` — space-padded — but %-d maps to Item::Numeric(Numeric::Day, Pad::None) in prqlc/prqlc/src/sql/dialect.rs, i.e. no padding at all. Space-padding is what %k (and chrono's %_d) does, and the table already documents %k separately as "space-padded". The neighbouring %-m row correctly shows 7 with no leading space.

Docs-only, so there's no test to add. Found during the nightly survey of web/book/src/reference/stdlib/date.md.

[prql-bot]

Verified the change by compiling against the Postgres dialect: date.to_text "%-d" emits TO_CHAR(d, 'FMDD'), and the FM prefix suppresses padding entirely — so 8 is the right example and the previous 8 was wrong.

One adjacent thing the same table gets wrong, outside this diff and left for a separate decision: the %k row (Same as %H but space-padded. Same as %_H.) is listed under "specifiers currently supported", but prqlc rejects it. chrono parses %k as Item::Numeric(Numeric::Hour, Pad::Space), and no dialect's translate_chrono_item in prqlc/prqlc/src/sql/dialect.rs has a Pad::Space arm — every one falls through to the unsupported-specifier error. Confirmed by running it: select { a = (d | date.to_text "%k") } fails with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql. Whether the fix is to drop the row or to add space-padding support to the dialect handlers needs a maintainer call, so it's not folded in here.

Sweep of every specifier in the table against `sql.postgres`

%k is the only failing row; the other 27 all compile:

%Y TO_CHAR(d, 'YYYY') %H TO_CHAR(d, 'HH24')
%y TO_CHAR(d, 'YY') %k ERROR — unsupported
%m TO_CHAR(d, 'MM') %I TO_CHAR(d, 'HH12')
%-m TO_CHAR(d, 'FMMM') %p TO_CHAR(d, 'AM')
%b TO_CHAR(d, 'Mon') %M TO_CHAR(d, 'MI')
%B TO_CHAR(d, 'FMMonth') %S TO_CHAR(d, 'SS')
%d TO_CHAR(d, 'DD') %f TO_CHAR(d, 'US')
%-d TO_CHAR(d, 'FMDD') %R TO_CHAR(d, 'HH24:MI')
%a TO_CHAR(d, 'Dy') %T TO_CHAR(d, 'HH24:MI:SS')
%A TO_CHAR(d, 'FMDay') %X TO_CHAR(d, 'HH24:MI:SS')
%D TO_CHAR(d, 'MM/DD/YY') %r TO_CHAR(d, 'HH12:MI:SS AM')
%x TO_CHAR(d, 'MM/DD/YY') %+ TO_CHAR(d, 'YYYY-MM-DD"T"HH24:MI:SS.USZ')
%F TO_CHAR(d, 'YYYY-MM-DD') %t %n %% literals

[prql-bot]

Reproduced the %k finding and filed it as #6139 so it isn't lost when this merges — date.to_text "%k" errors with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql, because no dialect's translate_chrono_item has a Pad::Space arm. The issue lays out both resolutions (drop the row vs. implement space-padding, which needs LPAD rather than a format string on Postgres) plus a related gap: %-H works but isn't in the table, even though %-m and %-d are.

Keeping this PR to the one-line %-d correction.

[prql-bot]

The %-d row in the date-specifier table shows its example as ` 8` — space-padded — but %-d maps to Item::Numeric(Numeric::Day, Pad::None) in prqlc/prqlc/src/sql/dialect.rs, i.e. no padding at all. Space-padding is what %k (and chrono's %_d) does, and the table already documents %k separately as "space-padded". The neighbouring %-m row correctly shows 7 with no leading space.

Docs-only, so there's no test to add. Found during the nightly survey of web/book/src/reference/stdlib/date.md.

[prql-bot]

Verified the change by compiling against the Postgres dialect: date.to_text "%-d" emits TO_CHAR(d, 'FMDD'), and the FM prefix suppresses padding entirely — so 8 is the right example and the previous 8 was wrong.

One adjacent thing the same table gets wrong, outside this diff and left for a separate decision: the %k row (Same as %H but space-padded. Same as %_H.) is listed under "specifiers currently supported", but prqlc rejects it. chrono parses %k as Item::Numeric(Numeric::Hour, Pad::Space), and no dialect's translate_chrono_item in prqlc/prqlc/src/sql/dialect.rs has a Pad::Space arm — every one falls through to the unsupported-specifier error. Confirmed by running it: select { a = (d | date.to_text "%k") } fails with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql. Whether the fix is to drop the row or to add space-padding support to the dialect handlers needs a maintainer call, so it's not folded in here.

Sweep of every specifier in the table against `sql.postgres`

%k is the only failing row; the other 27 all compile:

%Y TO_CHAR(d, 'YYYY') %H TO_CHAR(d, 'HH24')
%y TO_CHAR(d, 'YY') %k ERROR — unsupported
%m TO_CHAR(d, 'MM') %I TO_CHAR(d, 'HH12')
%-m TO_CHAR(d, 'FMMM') %p TO_CHAR(d, 'AM')
%b TO_CHAR(d, 'Mon') %M TO_CHAR(d, 'MI')
%B TO_CHAR(d, 'FMMonth') %S TO_CHAR(d, 'SS')
%d TO_CHAR(d, 'DD') %f TO_CHAR(d, 'US')
%-d TO_CHAR(d, 'FMDD') %R TO_CHAR(d, 'HH24:MI')
%a TO_CHAR(d, 'Dy') %T TO_CHAR(d, 'HH24:MI:SS')
%A TO_CHAR(d, 'FMDay') %X TO_CHAR(d, 'HH24:MI:SS')
%D TO_CHAR(d, 'MM/DD/YY') %r TO_CHAR(d, 'HH12:MI:SS AM')
%x TO_CHAR(d, 'MM/DD/YY') %+ TO_CHAR(d, 'YYYY-MM-DD"T"HH24:MI:SS.USZ')
%F TO_CHAR(d, 'YYYY-MM-DD') %t %n %% literals

[prql-bot]

Reproduced the %k finding and filed it as #6139 so it isn't lost when this merges — date.to_text "%k" errors with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql, because no dialect's translate_chrono_item has a Pad::Space arm. The issue lays out both resolutions (drop the row vs. implement space-padding, which needs LPAD rather than a format string on Postgres) plus a related gap: %-H works but isn't in the table, even though %-m and %-d are.

Keeping this PR to the one-line %-d correction.

[prql-bot]

The %-d row in the date-specifier table shows its example as ` 8` — space-padded — but %-d maps to Item::Numeric(Numeric::Day, Pad::None) in prqlc/prqlc/src/sql/dialect.rs, i.e. no padding at all. Space-padding is what %k (and chrono's %_d) does, and the table already documents %k separately as "space-padded". The neighbouring %-m row correctly shows 7 with no leading space.

Docs-only, so there's no test to add. Found during the nightly survey of web/book/src/reference/stdlib/date.md.

[prql-bot]

Verified the change by compiling against the Postgres dialect: date.to_text "%-d" emits TO_CHAR(d, 'FMDD'), and the FM prefix suppresses padding entirely — so 8 is the right example and the previous 8 was wrong.

One adjacent thing the same table gets wrong, outside this diff and left for a separate decision: the %k row (Same as %H but space-padded. Same as %_H.) is listed under "specifiers currently supported", but prqlc rejects it. chrono parses %k as Item::Numeric(Numeric::Hour, Pad::Space), and no dialect's translate_chrono_item in prqlc/prqlc/src/sql/dialect.rs has a Pad::Space arm — every one falls through to the unsupported-specifier error. Confirmed by running it: select { a = (d | date.to_text "%k") } fails with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql. Whether the fix is to drop the row or to add space-padding support to the dialect handlers needs a maintainer call, so it's not folded in here.

Sweep of every specifier in the table against `sql.postgres`

%k is the only failing row; the other 27 all compile:

%Y TO_CHAR(d, 'YYYY') %H TO_CHAR(d, 'HH24')
%y TO_CHAR(d, 'YY') %k ERROR — unsupported
%m TO_CHAR(d, 'MM') %I TO_CHAR(d, 'HH12')
%-m TO_CHAR(d, 'FMMM') %p TO_CHAR(d, 'AM')
%b TO_CHAR(d, 'Mon') %M TO_CHAR(d, 'MI')
%B TO_CHAR(d, 'FMMonth') %S TO_CHAR(d, 'SS')
%d TO_CHAR(d, 'DD') %f TO_CHAR(d, 'US')
%-d TO_CHAR(d, 'FMDD') %R TO_CHAR(d, 'HH24:MI')
%a TO_CHAR(d, 'Dy') %T TO_CHAR(d, 'HH24:MI:SS')
%A TO_CHAR(d, 'FMDay') %X TO_CHAR(d, 'HH24:MI:SS')
%D TO_CHAR(d, 'MM/DD/YY') %r TO_CHAR(d, 'HH12:MI:SS AM')
%x TO_CHAR(d, 'MM/DD/YY') %+ TO_CHAR(d, 'YYYY-MM-DD"T"HH24:MI:SS.USZ')
%F TO_CHAR(d, 'YYYY-MM-DD') %t %n %% literals

[prql-bot]

Reproduced the %k finding and filed it as #6139 so it isn't lost when this merges — date.to_text "%k" errors with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql, because no dialect's translate_chrono_item has a Pad::Space arm. The issue lays out both resolutions (drop the row vs. implement space-padding, which needs LPAD rather than a format string on Postgres) plus a related gap: %-H works but isn't in the table, even though %-m and %-d are.

Keeping this PR to the one-line %-d correction.

[prql-bot]

The %-d row in the date-specifier table shows its example as ` 8` — space-padded — but %-d maps to Item::Numeric(Numeric::Day, Pad::None) in prqlc/prqlc/src/sql/dialect.rs, i.e. no padding at all. Space-padding is what %k (and chrono's %_d) does, and the table already documents %k separately as "space-padded". The neighbouring %-m row correctly shows 7 with no leading space.

Docs-only, so there's no test to add. Found during the nightly survey of web/book/src/reference/stdlib/date.md.

[prql-bot]

Verified the change by compiling against the Postgres dialect: date.to_text "%-d" emits TO_CHAR(d, 'FMDD'), and the FM prefix suppresses padding entirely — so 8 is the right example and the previous 8 was wrong.

One adjacent thing the same table gets wrong, outside this diff and left for a separate decision: the %k row (Same as %H but space-padded. Same as %_H.) is listed under "specifiers currently supported", but prqlc rejects it. chrono parses %k as Item::Numeric(Numeric::Hour, Pad::Space), and no dialect's translate_chrono_item in prqlc/prqlc/src/sql/dialect.rs has a Pad::Space arm — every one falls through to the unsupported-specifier error. Confirmed by running it: select { a = (d | date.to_text "%k") } fails with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql. Whether the fix is to drop the row or to add space-padding support to the dialect handlers needs a maintainer call, so it's not folded in here.

Sweep of every specifier in the table against `sql.postgres`

%k is the only failing row; the other 27 all compile:

%Y TO_CHAR(d, 'YYYY') %H TO_CHAR(d, 'HH24')
%y TO_CHAR(d, 'YY') %k ERROR — unsupported
%m TO_CHAR(d, 'MM') %I TO_CHAR(d, 'HH12')
%-m TO_CHAR(d, 'FMMM') %p TO_CHAR(d, 'AM')
%b TO_CHAR(d, 'Mon') %M TO_CHAR(d, 'MI')
%B TO_CHAR(d, 'FMMonth') %S TO_CHAR(d, 'SS')
%d TO_CHAR(d, 'DD') %f TO_CHAR(d, 'US')
%-d TO_CHAR(d, 'FMDD') %R TO_CHAR(d, 'HH24:MI')
%a TO_CHAR(d, 'Dy') %T TO_CHAR(d, 'HH24:MI:SS')
%A TO_CHAR(d, 'FMDay') %X TO_CHAR(d, 'HH24:MI:SS')
%D TO_CHAR(d, 'MM/DD/YY') %r TO_CHAR(d, 'HH12:MI:SS AM')
%x TO_CHAR(d, 'MM/DD/YY') %+ TO_CHAR(d, 'YYYY-MM-DD"T"HH24:MI:SS.USZ')
%F TO_CHAR(d, 'YYYY-MM-DD') %t %n %% literals

[prql-bot]

Reproduced the %k finding and filed it as #6139 so it isn't lost when this merges — date.to_text "%k" errors with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql, because no dialect's translate_chrono_item has a Pad::Space arm. The issue lays out both resolutions (drop the row vs. implement space-padding, which needs LPAD rather than a format string on Postgres) plus a related gap: %-H works but isn't in the table, even though %-m and %-d are.

Keeping this PR to the one-line %-d correction.

[prql-bot]

The %-d row in the date-specifier table shows its example as ` 8` — space-padded — but %-d maps to Item::Numeric(Numeric::Day, Pad::None) in prqlc/prqlc/src/sql/dialect.rs, i.e. no padding at all. Space-padding is what %k (and chrono's %_d) does, and the table already documents %k separately as "space-padded". The neighbouring %-m row correctly shows 7 with no leading space.

Docs-only, so there's no test to add. Found during the nightly survey of web/book/src/reference/stdlib/date.md.

[prql-bot]

Verified the change by compiling against the Postgres dialect: date.to_text "%-d" emits TO_CHAR(d, 'FMDD'), and the FM prefix suppresses padding entirely — so 8 is the right example and the previous 8 was wrong.

One adjacent thing the same table gets wrong, outside this diff and left for a separate decision: the %k row (Same as %H but space-padded. Same as %_H.) is listed under "specifiers currently supported", but prqlc rejects it. chrono parses %k as Item::Numeric(Numeric::Hour, Pad::Space), and no dialect's translate_chrono_item in prqlc/prqlc/src/sql/dialect.rs has a Pad::Space arm — every one falls through to the unsupported-specifier error. Confirmed by running it: select { a = (d | date.to_text "%k") } fails with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql. Whether the fix is to drop the row or to add space-padding support to the dialect handlers needs a maintainer call, so it's not folded in here.

Sweep of every specifier in the table against `sql.postgres`

%k is the only failing row; the other 27 all compile:

%Y TO_CHAR(d, 'YYYY') %H TO_CHAR(d, 'HH24')
%y TO_CHAR(d, 'YY') %k ERROR — unsupported
%m TO_CHAR(d, 'MM') %I TO_CHAR(d, 'HH12')
%-m TO_CHAR(d, 'FMMM') %p TO_CHAR(d, 'AM')
%b TO_CHAR(d, 'Mon') %M TO_CHAR(d, 'MI')
%B TO_CHAR(d, 'FMMonth') %S TO_CHAR(d, 'SS')
%d TO_CHAR(d, 'DD') %f TO_CHAR(d, 'US')
%-d TO_CHAR(d, 'FMDD') %R TO_CHAR(d, 'HH24:MI')
%a TO_CHAR(d, 'Dy') %T TO_CHAR(d, 'HH24:MI:SS')
%A TO_CHAR(d, 'FMDay') %X TO_CHAR(d, 'HH24:MI:SS')
%D TO_CHAR(d, 'MM/DD/YY') %r TO_CHAR(d, 'HH12:MI:SS AM')
%x TO_CHAR(d, 'MM/DD/YY') %+ TO_CHAR(d, 'YYYY-MM-DD"T"HH24:MI:SS.USZ')
%F TO_CHAR(d, 'YYYY-MM-DD') %t %n %% literals

[prql-bot]

Reproduced the %k finding and filed it as #6139 so it isn't lost when this merges — date.to_text "%k" errors with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql, because no dialect's translate_chrono_item has a Pad::Space arm. The issue lays out both resolutions (drop the row vs. implement space-padding, which needs LPAD rather than a format string on Postgres) plus a related gap: %-H works but isn't in the table, even though %-m and %-d are.

Keeping this PR to the one-line %-d correction.