Open andreubotella opened 1 year ago
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.
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.
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 https://github.com/date-fns/date-fns/issues/489 but looks like there's not way to pass a timezone for formatting.
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:date-fns@2.30.0";
dayjs: 11.4 kb
import dayjs from 'npm:dayjs@1.11.7';
// Timezone plugin depends on this
import utc from 'npm:dayjs@1.11.7/plugin/utc.js';
import timezone from 'npm:dayjs@1.11.7/plugin/timezone.js';
dayjs.extend(utc);
dayjs.extend(timezone);
export default dayjs;
@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).
Temporal API is stable in Deno 1.40 now: https://deno.com/blog/v1.40 :)
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.
Ah, I misread. Sorry.
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 todate("ATOM")
in a UTC timezone, but sincetoISOString
is a standard, it would be useful to also make it available regardless of the timezone set in the plugin options.