Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The date plugin should support specifying a timezone #391

Open
andreubotella opened this issue Mar 2, 2023 · 8 comments
Open

The date plugin should support specifying a timezone #391

andreubotella opened this issue Mar 2, 2023 · 8 comments
Labels
enhancement New feature or request

Comments

@andreubotella
Copy link

andreubotella commented Mar 2, 2023

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.

@andreubotella andreubotella added the enhancement New feature or request label Mar 2, 2023
@oscarotero
Copy link
Member

oscarotero commented Mar 2, 2023

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
Copy link
Author

andreubotella commented Mar 2, 2023

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
Copy link
Member

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
Copy link
Contributor

binyamin commented May 7, 2023

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
Copy link
Member

@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
Copy link

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

@oscarotero
Copy link
Member

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
Copy link

Ah, I misread. Sorry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants