The date plugin should support specifying a timezone

[andreubotella]

Enter your suggestions in details:

Currently, the date plugin uses the system's default timezone. This can result in a difference between local testing and deployment, if the build for deployment uses CI (Github Actions uses the UTC timezone, for example, although this is configurable).

The timezone to use should be able to be set in the plugin's options, but it would also be nice to have a format that will display a date as with Date.prototype.toISOString. This is equivalent to date("ATOM") in a UTC timezone, but since toISOString is a standard, it would be useful to also make it available regardless of the timezone set in the plugin options.

[oscarotero]

The only way I know to set a timezone that works consistently everywhere (not only with date plugin but also anywhere you do a new Date(), is by setting the TZ environment variable.

This is what I use in the task for tests: https://github.com/lumeland/lume/blob/master/deno.json#L4

So I recommend to edit your lume task to include this environment variable with your timezone of choice.

It might be configurable in the date plugin options (there's a package to convert dates to different timezones https://date-fns.org/v2.29.3/docs/Time-Zones) but not sure if it's the best way, because it would work only at plugin level, to format a date. The dates defined in frontmatters or filenames (like 2022-01-01_hello.md) would be created with the system's timezone, and this could affect to order the pages by date, or to select pages from a specific date.

[andreubotella]

In my (WIP) blog I'm using "git created" by default, and overriding that when needed with ISO timestamps, so I don't run into this issue when parsing dates. But yeah, it is an issue in general. Whenever the temporal proposal ships, it should allow parsing dates with a timezone option, but I'm not sure if it would allow the variety of date formats that new Date() supports.

I framed this issue specifically about date formatting because of that, but if you think any such options should also apply to date parsing, that's fine. I can define a custom date filter, so this is not a blocker for me.

[oscarotero]

Yeah, I think temporal should make things more easy.

If you find a simple way to have this in the date plugin, please let me know. There are some issues in date-fns related with this date-fns/date-fns#489 but looks like there's not way to pass a timezone for formatting.

[binyamin]

I recommend switching to dayjs (repo). It's smaller, and its many plugins include a timezone plugin.

I did some tests. I used esbuild to bundle & minify the following code, with tree-shaking enabled. Here are the results.

date-fns: 23.4kb

export { format } from "npm:[email protected]";

dayjs: 11.4 kb

import dayjs from 'npm:[email protected]';

// Timezone plugin depends on this
import utc from 'npm:[email protected]/plugin/utc.js';
import timezone from 'npm:[email protected]/plugin/timezone.js';

dayjs.extend(utc);
dayjs.extend(timezone);

export default dayjs;

[oscarotero]

@binyamin dayjs looks nice but the available formats are different from date-fns: dayjs vs date-fns, so it would break things.

I'd rather to wait until I can switch to something more standard like the Temporal API or even the Intl API that doesn't require any external dependency and it's already supported by Deno (but it's buggy in my native language, Galician, so I cannot use it for now).

[brookback]

Temporal API is stable in Deno 1.40 now: https://deno.com/blog/v1.40 :)

[oscarotero]

It's not stable yet, it requires the --unstable-temporal flag.
But Lume 2 comes with the temporal polyfill as a dependency, so maybe it can be used to modify the timezone of a specific date.

[brookback]

Ah, I misread. Sorry.