chore(deps): bump the date-fns group across 1 directory with 2 updates

[dependabot]

⚠️ Dependabot is rebasing this PR ⚠️

Rebasing might not happen immediately, so don't worry if this takes some time.

Note: if you make any changes to this PR yourself, they will take precedence over the rebase.

---

⚠️ Dependabot is rebasing this PR ⚠️

Rebasing might not happen immediately, so don't worry if this takes some time.

Note: if you make any changes to this PR yourself, they will take precedence over the rebase.

---

⚠️ Dependabot is rebasing this PR ⚠️

Rebasing might not happen immediately, so don't worry if this takes some time.

Note: if you make any changes to this PR yourself, they will take precedence over the rebase.

---

Bumps the date-fns group with 2 updates in the / directory: date-fns and date-fns-tz.

Updates date-fns from 2.30.0 to 4.1.0

Release notes

Sourced from date-fns's releases.

v4.1.0

This release adds time zone support to format functions (that I somehow missed when working on the feature) and fixes a few bugs.

Make sure also upgrade TZDate to v1.0.2 as it includes a bunch of critical bug fixes.

Fixed

• Fixed internal constructFrom throwing an exception on null arguments. While null isn't allowed, the functions should rather return Invalid Date or NaN in such cases. See #3885.

Added

• Added missing time zone support to format, formatISO, formatISO9075, formatRelative and formatRFC3339. See #3886.

v4.0.0

I have great news! First, ten years after its release, date-fns finally gets first-class time zone support.

Another great news is that there aren't many breaking changes in this release. All of them are type-related and will affect only those explicitly using internal date-fns types. Finally, it has been less than a year since the last major release, which is an improvement over the previous four years between v2 and v3. I plan on keeping the pace and minimizing breaking changes moving forward.

Read more about the release in the announcement blog post.

- Sasha @​kossnocorp

Added

• Added time zones support via @date-fns/tz's TZDate class and tz helper function. See its README for the details about the API.

• All relevant functions now accept the context in option, which allows to specify the time zone to make the calculations in. If the function also returns a date, it will be in the specified time zone:

  import { addDays, startOfDay } from "date-fns";
  import { tz } from "@date-fns/tz";
  startOfDay(addDays(Date.now(), 5, { in: tz("Asia/Singapore") }));
  //=> "2024-09-16T00:00:00.000+08:00"

  In the example, addDays will get the current date and time in Singapore and add 5 days to it. startOfDay will inherit the date type and return the start of the day in Singapore.

Changed

• The function arguments, as well as Interval's start and end, now can be of different types, allowing you to mix UTCDate, TZDate, Date, and other extensions, as well as primitives (strings and numbers).

  The functions will normalize these values, make calculations, and return the result in the same type, preventing any bugs caused by the discrepancy. If passed, the type will be inferred from the context in option or the first encountered argument object type. The Interval's start and end will be considered separately, starting from start.

  In the given example, the result will be in the TZDate as the first argument is a number, and the start takes precedence over the end.

  clamp(Date.now(), {
    start: new TZDate(start, "Asia/Singapore"),
    end: new UTCDate(),

... (truncated)

Changelog

Sourced from date-fns's changelog.

v4.1.0 - 2024-09-17

This release adds time zone support to format functions (that I somehow missed when working on the feature) and fixes a few bugs.

Make sure also upgrade TZDate to v1.0.2 as it includes a bunch of critical bug fixes.

Fixed

• Fixed internal constructFrom throwing an exception on null arguments. While null isn't allowed, the functions should rather return Invalid Date or NaN in such cases. See #3885.

Added

• Added missing time zone support to format, formatISO, formatISO9075, formatRelative and formatRFC3339. See #3886.

v4.0.0 - 2024-09-16

I have great news! First, ten years after its release, date-fns finally gets first-class time zone support.

Another great news is that there aren't many breaking changes in this release. All of them are type-related and will affect only those explicitly using internal date-fns types. Finally, it has been less than a year since the last major release, which is an improvement over the previous four years between v2 and v3. I plan on keeping the pace and minimizing breaking changes moving forward.

Read more about the release in the announcement blog post.

- Sasha @​kossnocorp

Added

• Added time zones support via @date-fns/tz's TZDate class and tz helper function. See its README for the details about the API.

• All relevant functions now accept the context in option, which allows to specify the time zone to make the calculations in. If the function also returns a date, it will be in the specified time zone:

  import { addDays, startOfDay } from "date-fns";
  import { tz } from "@date-fns/tz";
  startOfDay(addDays(Date.now(), 5, { in: tz("Asia/Singapore") }));
  //=> "2024-09-16T00:00:00.000+08:00"

  In the example, addDays will get the current date and time in Singapore and add 5 days to it. startOfDay will inherit the date type and return the start of the day in Singapore.

Changed

• The function arguments, as well as Interval's start and end, now can be of different types, allowing you to mix UTCDate, TZDate, Date, and other extensions, as well as primitives (strings and numbers).

  The functions will normalize these values, make calculations, and return the result in the same type, preventing any bugs caused by the discrepancy. If passed, the type will be inferred from the context in option or the first encountered argument object type. The Interval's start and end will be considered separately, starting from start.

  In the given example, the result will be in the TZDate as the first argument is a number, and the start takes precedence over the end.

  clamp(Date.now(), {

... (truncated)

Commits

• 313b902 Fix v4.1.0 change log entry
• 26cd336 Promote to v4.1.0
• 97b53b9 Cover time zone edge cases
• 59b7563 Add missing time zone support to format, formatISO, formatISO9075, formatRela...
• 0121164 Prevent constructFrom from throwing an error on null
• bd87ef5 Update @​date-fns/docs
• 99b4e67 Prepare v4.0
• 8df1706 Rewrite the time zones doc
• e351977 Promote to v4.0.0-beta.1
• 8523656 Fix scripts/test/types.sh
• Additional commits viewable in compare view

Updates date-fns-tz from 2.0.0 to 3.2.0

Release notes

Sourced from date-fns-tz's releases.

v3.0.0

This release adds support for date-fns v3. Thank you @​christopherklint97 (#265) and everyone who helped test and fix the beta releases.

BREAKING CHANGES

• date-fns v2 is no longer supported
• Renamed utcToZonedTime to toZonedTime to make the name less confusing, just search & replace
• Renamed zonedTimeToUtc to fromZonedTime to make the name less confusing, just search & replace
• All functions are now exported using named exports, this requires changing direct imports from import formatInTimeZone from 'date-fns-tz/formatInTimeZone' to import { formatInTimeZone } from 'date-fns-tz/formatInTimeZone'
• Functions now don’t check the number of passed arguments, delegating this task to type checkers similar to date-fns v3
• Arguments are not explicitly converted to the target types; instead, they are passed as is, delegating this task to type checkers similar to date-fns v3
• IE is no longer supported since date-fns no longer supports it
• Removed flow support since date-fns also removed it

Changelog

Sourced from date-fns-tz's changelog.

v3.2.0 (27 September 2024)

• [DEPS] [email protected] supported (#301)
• [PERFORMANCE] Make testDateFormatted static to avoid re-initialising it on every call (#297) @​hurali97
• [ENHANCEMENT] Compatibility with date-fns setDefaultOptions (#286) @​yangchristina
• [DOCS] Fixed table of contents links (#284)

v3.1.3 (17 April 2024)

• [BUGFIX] Make getTimeZoneOffset's 2nd arg optional

v3.1.2 (16 April 2024)

• [BUGFIX] Fix formatInTimeZone use of timeZone string (#280)

v3.1.1 (16 April 2024)

• [BUGFIX] getTimeZoneOffset's 2nd arg should be optional (#281)

v3.1.0 (15 April 2024)

• [REFACTOR] Full rewrite in TypeScript (#278) Thank you, @​brettwillis
• [BREAKING CHANGE] OptionsWithTZ is now either FormatOptionsWithTZ or ToDateOptionsWithTZ, matching date-fns

v3.0.1 (10 April 2024)

• [BUGFIX] Fix named export typings (#277)

v3.0.0 (6 April 2024)

• [UPGRADE] Support date-fns v3 (#265) Thank you, @​christopherklint97
• [BUGFIX] Correct import of date-fns@v3 format and use Babel Webpack loader for mjs files (#271)
• [BREAKING CHANGE] date-fns v2 is no longer supported
• [BREAKING CHANGE] Renamed utcToZonedTime to toZonedTime to make the name less confusing, just search & replace
• [BREAKING CHANGE] Renamed zonedTimeToUtc to fromZonedTime to make the name less confusing, just search & replace
• [BREAKING CHANGE] All functions are now exported using named exports, this requires changing direct imports from import formatInTimeZone from 'date-fns-tz/formatInTimeZone' to import { formatInTimeZone } from 'date-fns-tz/formatInTimeZone'
• [BREAKING CHANGE] Functions now don’t check the number of passed arguments, delegating this task to type checkers (This isn't fully implemented yet, but it should be the assumption moving forward, as it is in date-fns)
• [BREAKING CHANGE] Arguments are not explicitly converted to the target types. Instead, they are passed as is, delegating this task to type checkers (This isn't fully implemented yet, but it should be the assumption moving forward, as it is in date-fns)
• [BREAKING CHANGE] IE is no longer supported since date-fns no longer supports it
• [BREAKING CHANGE] Removed flow support since date-fns also removed it

v2.0.1 (9 March 2024)

• [DOCS] Fix incorrect output comment (#270)
• [DEPS] Limit to date-fns 2.x (#262, #267)

... (truncated)

Commits

• b882090 3.2.0
• 62b11e3 Peer dep date-fns ^3.0.0 || ^4.0.0
• 142a409 Merge pull request #286 from yangchristina/get-default-options
• 9877487 Merge pull request #297 from callstack-internal/hur/perf/extract-testDateForm...
• 772f07c Merge pull request #284 from yangchristina/docs
• e7a6122 Merge pull request #301 from eshimischi/master
• 16a355b Yarn: upgrade
• 7ecd332 Merge pull request #1 from eshimischi/eshimischi-patch-1
• a70c07a date-fns v4.1.0
• 79bb229 perf: extract testDateFormatted to avoid re-initialising each time getDateTie...
• Additional commits viewable in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[changelog-app]

Generate changelog in packages/datetime/changelog/@unreleased

What do the change types mean?

• feature: A new feature of the service.
• improvement: An incremental improvement in the functionality or operation of the service.
• fix: Remedies the incorrect behaviour of a component of the service in a backwards-compatible way.
• break: Has the potential to break consumers of this service's API, inclusive of both Palantir services
  and external consumers of the service's API (e.g. customer-written software or integrations).
• deprecation: Advertises the intention to remove service functionality without any change to the
  operation of the service itself.
• manualTask: Requires the possibility of manual intervention (running a script, eyeballing configuration,
  performing database surgery, ...) at the time of upgrade for it to succeed.
• migration: A fully automatic upgrade migration task with no engineer input required.

Note: only one type should be chosen.

How are new versions calculated?

• ❗The break and manual task changelog types will result in a major release!
• 🐛 The fix changelog type will result in a minor release in most cases, and a patch release version for patch branches. This behaviour is configurable in autorelease.
• ✨ All others will result in a minor version release.

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

chore(deps): bump the date-fns group across 1 directory with 2 updates

---

Generate changelog in packages/datetime2/changelog/@unreleased

What do the change types mean?

• feature: A new feature of the service.
• improvement: An incremental improvement in the functionality or operation of the service.
• fix: Remedies the incorrect behaviour of a component of the service in a backwards-compatible way.
• break: Has the potential to break consumers of this service's API, inclusive of both Palantir services
  and external consumers of the service's API (e.g. customer-written software or integrations).
• deprecation: Advertises the intention to remove service functionality without any change to the
  operation of the service itself.
• manualTask: Requires the possibility of manual intervention (running a script, eyeballing configuration,
  performing database surgery, ...) at the time of upgrade for it to succeed.
• migration: A fully automatic upgrade migration task with no engineer input required.

Note: only one type should be chosen.

How are new versions calculated?

• ❗The break and manual task changelog types will result in a major release!
• 🐛 The fix changelog type will result in a minor release in most cases, and a patch release version for patch branches. This behaviour is configurable in autorelease.
• ✨ All others will result in a minor version release.

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

chore(deps): bump the date-fns group across 1 directory with 2 updates

---

Generate changelog in packages/docs-app/changelog/@unreleased

What do the change types mean?

• feature: A new feature of the service.
• improvement: An incremental improvement in the functionality or operation of the service.
• fix: Remedies the incorrect behaviour of a component of the service in a backwards-compatible way.
• break: Has the potential to break consumers of this service's API, inclusive of both Palantir services
  and external consumers of the service's API (e.g. customer-written software or integrations).
• deprecation: Advertises the intention to remove service functionality without any change to the
  operation of the service itself.
• manualTask: Requires the possibility of manual intervention (running a script, eyeballing configuration,
  performing database surgery, ...) at the time of upgrade for it to succeed.
• migration: A fully automatic upgrade migration task with no engineer input required.

Note: only one type should be chosen.

How are new versions calculated?

• ❗The break and manual task changelog types will result in a major release!
• 🐛 The fix changelog type will result in a minor release in most cases, and a patch release version for patch branches. This behaviour is configurable in autorelease.
• ✨ All others will result in a minor version release.

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

chore(deps): bump the date-fns group across 1 directory with 2 updates

---

Check the box to generate changelog(s)

• Generate changelog entry