Hi,

It would be great to have the possibility to call a function that set the locale globally, instead of having to wrap date-fns functions. Something similar to moment.locale() where we would pass the imported locale.

Thanks !

I'm using date-fns in two projects (without additional locales) and when I upgraded to 2.17 the bundle size went to ~200Kb.

Checked with the webpack bundle analyzer, and all the functions seem to be there. I'm actually using just 7 functions with import syntax (ESM), so nothing changed from my side. If I rollback to 2.16.1, everything is OK again.

Does it have to do with the Typescript addition? My projects are plain js.

Functions to work with durations, like http://momentjs.com/docs/#/durations/ also #277

Seems like it is an anticipated feature: https://www.reddit.com/r/javascript/comments/5gl51e/a_modern_javascript_date_utility_library/daucfia/ https://www.reddit.com/r/javascript/comments/5gl51e/a_modern_javascript_date_utility_library/dat91yu/

Not sure about API. If someone has suggestions, please post them here

I recently encountered a phenomenon in date-fns that broke a Node.js script of mine:

const d = new Date('2017-01-23');
console.log(format(d, 'YYYY-MM-DD'));

This code logs 2017-01-23 in Germany, but 2017-01-22 in Seattle.

How do I best fix this to always log 2017-01-23? Specify a time zone? How? It may make sense to warn about this in the docs.

Under version 1, formatDate supported the following formatting options:

Pattern|Result examples -- | -- A| AM, PM a | am, pm aa | a.m., p.m.

but version 2 only has these options:

Pattern|Result examples -- | -- a..aaa | AM, PM |   aaaa | a.m., p.m. aaaaa | a, p

The style guide for the site I'm working on requires "am" and "pm" — lower case, no dots. Would it be possible to reinstate an option to have "am" and "pm"? (Perhaps as "aaa" if that doesn't break compatibility with anything…)

I'd rather not have to mess about with reformatting the output from the formatter (if it was down to me, I'd format times in 24-hour clock and be done with it :)

Thanks

I'm using the addMonths function to add 1 month to a given date. The function is inside a forEach but that doesn't add nothing to the bug.

Receiving the date 2019-03-01T01:00:00.000Z and adding 1 month to it dateFns.addMonths(actualDate, 1) (actualDate is the referred date object) results in 2019-04-29T01:00:00.000Z when it should result 2019-05-01T01:00:00.000Z. I tried starting in 2019-01-01 and add 1 month to each new date. Here are the resulting dates:

2019-02-01T00:00:00.000Z
2019-03-01T01:00:00.000Z
2019-03-29T01:00:00.000Z
2019-04-29T01:00:00.000Z
2019-05-29T01:00:00.000Z
2019-06-29T01:00:00.000Z
2019-07-29T01:00:00.000Z
2019-08-29T01:00:00.000Z
2019-09-29T01:00:00.000Z
2019-10-29T01:00:00.000Z

Beginning in 2018-01-01, the resulting dates are:

2018-02-01T00:00:00.000Z
2018-03-01T01:00:00.000Z
2018-03-29T01:00:00.000Z
2018-04-29T01:00:00.000Z
2018-05-29T01:00:00.000Z
2018-06-29T01:00:00.000Z
2018-07-29T01:00:00.000Z
2018-08-29T01:00:00.000Z
2018-09-29T01:00:00.000Z
2018-10-29T01:00:00.000Z
2018-11-29T00:00:00.000Z
2018-12-29T00:00:00.000Z
2019-01-29T00:00:00.000Z
2019-03-01T01:00:00.000Z
2019-03-29T01:00:00.000Z
2019-04-29T01:00:00.000Z
2019-05-29T01:00:00.000Z
2019-06-29T01:00:00.000Z
2019-07-29T01:00:00.000Z
2019-08-29T01:00:00.000Z
2019-09-29T01:00:00.000Z
2019-10-29T01:00:00.000Z

My nodejs version is 12.12.0 and date-fns version is 2.6.0

I've built on the addition in #676 by @benmccann and tried to figure out what an API / helper functions for time zone support might look like which would solve the use cases presented in #180. Key additions are the two time zone helper functions:

• setTimeZone for getting a Date instance with the time at a given time zone
• dateAtTimeZone for getting a Date with the UTC value of a time in a given time zone

The toDate, format and parse functions also have additional time zone support added.

For a more complete discussion of the new functionality see the Time zone documentation included in this PR.

The date-fns library aims to support IE8+ (see #660). This PR proposes using the Intl API for IANA time zone support which requires a polyfill in older browsers. As a compromise, all new time zone functionality fully supports the use of time zone offset values (+0200, -04:00 etc.) which will work back to IE8. If you wish to use IANA time zones a polyfill will be needed though.

Calculating differenceInDays fails across DST

Example: For London 2017-03-26, 01:00 clocks were turned forward 1 hour to 02:00 https://www.timeanddate.com/time/change/uk/london?year=2017

const d1 = new Date(2017, 2, 27, 1);
const d2 = new Date(2017, 2, 26, 2);
differenceInDays(d1, d2) === 1 // should be '0'

Hello! This is my first PR here. I struggle a bit to end it... For the "match" part and a JS function called ordinalNumber in Localize. If someone could give me some hints.

Thanks!

closes #2061

If I run tsc --noEmit --incremental false I get a long list of Cannot augment... error messages. Everything was fine with 2.10.0 but fails now with 2.11.0

...
node_modules/date-fns/typings.d.ts:15311:9 - error TS2649: Cannot augment module 'ro' with value exports because it resolves to a non-module entity.

15311   const ro: Locale
              ~~

node_modules/date-fns/typings.d.ts:15314:9 - error TS2649: Cannot augment module 'ru' with value exports because it resolves to a non-module entity.

15314   const ru: Locale
              ~~

node_modules/date-fns/typings.d.ts:15317:9 - error TS2649: Cannot augment module 'sk' with value exports because it resolves to a non-module entity.
...

Is there any way to do like this by date-fns?

let now = new Date().getTime();
// after some time...
moment.utc(new Date().getTime() - now).format(' ( HH:mm:ss )');

date-fns has formatDistance() ,but I don't need the result in words.

I'm wondering if this function doesn't exist because there's some sort of inherit limitation to it? Or if it's just that no one else needs it?

I'm looking for a getIsoMonth function.

You give it a date, or a weekYear. It returns the month it belongs to (under ISO way of counting).

examples: "2022-01-01" -> "December" "2022-03-01" -> "February" "2022-03-07" -> "March"

also fine if the function returns: "2022-01-01" -> "2021-12"

See commit messages for more info.

I added a start of a test.ts file for the icelandic locale, focusing on the parsing patterns, which were badly broken.

In addition to fixing typos in the matching and parsing patterns, I also made the matchers way (!) more forgiving/lenient in terms of the "width" of the mathced pattern, to better adhere to the Robustness Principle.

The start of the day for en-IN is Sunday rather than Monday as per the ISO 8601.

Ref: https://metacpan.org/dist/DateTime-Locale/view/lib/DateTime/Locale/en_IN.pod#Local-first-day-of-the-week https://help.salesforce.com/s/articleView?id=000387765&type=1

or

try this in any browser console

new Intl.Locale("en-in").weekInfo

resolves #3291 As discussed in issue it was simple issue with the formatting of output and test was passing as it was also expecting the wrong fomrat.

Made follwing changes in src/formatISO

1. Updated the index.ts file in src/formatISO to check for the basic option and format the result without the collon.
2. And updated the src/formatISO/test.ts to check for the right format without collon.