Allow a timezone configuration for partial date handling
See original GitHub issueCurrently, if I set a field to the date type and enter a partial date, e.g., 2021-10-21 I’m given a date object initialized with a value in UTC, like this 2021-10-21T00:00:00.000Z. Ideally I’d be able to have that partial date interpreted correctly for my timezone — I’m in America/New_York so I’d like to see 2021-10-21T04:00:00.000Z.
A possible, straightforward solution would be the date-fns-tz libraries zonedTimeToUtc function and an optional IANA timezone in the contentlayer config. E.g.
zonedTimeToUtc(doc.createdAt, opts.timezone)
If you’re interested in a contribution I could work on a PR.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:6 (2 by maintainers)
Top Results From Across the Web
Working with Time Zones - W3C
Date and time values based on incremental time are time-zone-independent, since at any given moment it is the same time in UTC everywhere:...
Read more >How to format DateComponents as a partial date string?
I've tried DateComponentsFormatter but none of the properties get anywhere near what I'd like to see. let components = DateComponents(calendar: ...
Read more >Settings — DateParser 1.1.2 documentation - Read the Docs
RELATIVE_BASE : allows setting the base datetime to use for interpreting partial or relative date strings. Defaults to the current date and time....
Read more >Partial Date | Drupal.org
This module provides date and time fields that allows any individual component to be left blank, while still providing a sortable listing of...
Read more >Dates and times | Google developer documentation style guide
Partial dates and abbreviations; Dates in the middle of a sentence ... If a time zone is necessary, use the timestamp format as...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

Apologies for the long delay in testing this, but I was trying out the feature today and noticed a couple things:
Minor issue
The
makeSourcefn is being exported without the correct types for this feature. It looks like thePartialArgstype incorewas updated, butmakeSourceis exported with a customArgstype passed to the generic.Larger issue
The utility of this option doesn’t work as I would have imagined. In my custom solution for this issue I treated my field
publishedAtas a string, and passed that string tozonedTimeToUtc. This has the result of interpreting the string value in the specific timezone, and then doing the timezone offset. So, the partial date string is converted from2020-10-20to2021-10-20T04:00:00.000Z.The option not working as expected is due to this line: https://github.com/contentlayerdev/contentlayer/blob/589aa04099f6d096064cb699b5af95a771e75e05/packages/%40contentlayer/source-files/src/fetchData/mapping.ts#L244
If that date object were created only if we don’t need to use
zonedTimeToUtcthen things should work correctly assuming I specify the frontmatter field in my markdown as an explicit string.If I add the field without the quotes though, I think
gray-matteris turning it into aDateobject before you touch it. I’m not sure if it’s even an option, but since you apply typing explicitly incontentlayerit might make sense to have gray-matter treat the field as a string no matter what, so that you can control when / how it is turned into aDate, and can offer a consistent user experience for the newtimezoneoption — meaning, they can get the TZ applied whether they specify the partial date as a quoted string or an unquoted date-string.This should be addressed with the
0.2.7release. 🎉