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

differenceInSeconds() returns -0 when comparing the same date with millisecond differences #2555

Closed
ashutoshrishi opened this issue Jul 22, 2021 · 6 comments · Fixed by #2571

Comments

@ashutoshrishi
Copy link

ashutoshrishi commented Jul 22, 2021

let d = new Date("2021-07-22T06:01:28.973Z")
let e = new Date("2021-07-22T06:01:28.976Z")

differenceInSeconds(d, e)
// -0

differenceInSeconds(d, d)
// 0

I have tested this with the latest version 2.22.1. There is an older issue and test to prevent the negative 0, so maybe this is a regression?

https://github.com/date-fns/date-fns/blob/master/src/differenceInSeconds/index.ts#L36

For the above 2 dates, the differenceInMilliseconds is -0.003 and Math.ceil(-0.003) is -0.

@pabrodez
Copy link

pabrodez commented Jul 28, 2021

I wouldn't mind date-fns returning -0 in the differenceIn* functions, but Object.is(0, -0) === false : (

What about Number((diff).toString()) ? Returns 0 for -0

@tan75 tan75 linked a pull request Aug 2, 2021 that will close this issue
kossnocorp added a commit that referenced this issue Sep 17, 2021
…#2555)

Added `roundingMethod` option to `differenceInHours`, `differenceInMinutes`, `differenceInQuarters`, `differenceInSeconds` and `differenceInWeeks` with `trunc` as the default method. 

Co-authored-by: Lucas Silva <lucas.silva@codeminer42.com>
Co-authored-by: Tetiana <ttobin@protonmail.ch>
Co-authored-by: Sasha Koss <koss@nocorp.me>
tan75 added a commit to janziemba/date-fns that referenced this issue Dec 27, 2021
closes date-fns#2555)

Added `roundingMethod` option to `differenceInHours`, `differenceInMinutes`, `differenceInQuarters`, `differenceInSeconds` and `differenceInWeeks` with `trunc` as the default method. 

Co-authored-by: Lucas Silva <lucas.silva@codeminer42.com>
Co-authored-by: Tetiana <ttobin@protonmail.ch>
Co-authored-by: Sasha Koss <koss@nocorp.me>
@utluiz
Copy link

utluiz commented Jan 11, 2024

I was hit with this issue. Maybe another regression or a different scenario.

test('check', () => {
  const dateLeft = new Date(1694143833566)
  const dateRight = new Date(1694143833567)
  const result = differenceInSeconds(dateLeft, dateRight)
  expect(result).toBe(0)
})

Results in:

Error: expect(received).toBe(expected) // Object.is equality

Expected: 0
Received: -0

The issue happens when the dateLeft is lower than dateRight by an order of magnitude lower than the different unit, so while the result is zero, it still yields a negative result.

@kossnocorp
Copy link
Member

kossnocorp commented Jan 11, 2024

A PR is welcome! The easiest solution is result || 0 (-0 || 0). I would also appreciate a breakdown of why it happens and if we have to fix it for every function that returns numbers (except ones that return Date values like getMonths). Thanks!

@kossnocorp kossnocorp reopened this Jan 11, 2024
@kossnocorp
Copy link
Member

Fixed and shipped with v3.3.0: https://github.com/date-fns/date-fns/releases/tag/v3.3.0

@utluiz
Copy link

utluiz commented Feb 1, 2024

Thank you @kossnocorp

FWIW I missed your last update otherwise I'd be glad to git it a shot.

The reason for the -0 was because the diff computation results in a negative fraction that rounds to zero. Then one of those JS quirks kicks in and the minus sign is preserved.

For instance, you can try something like this in any console:

console.log(Math.round(0.001 - 0.002))
-0

So effectively, any routine that rounds or ceils fractions can have this issue.

As for a solution, the workaround I applied to my application as adding a zero:

console.log(Math.round(0.001 - 0.002) + 0)
0

Basically adding +0 after calls to Math.round and Math.ceil would also do it I think.

@martinhipp
Copy link

Thanks @kossnocorp, any chance of the negative number fixes in v3.3.0 could be backported to v2? Unfortunately I am unable to upgrade to v3, all good if it is too much of an ask, I have fixed it manually, but assume it probably affects a few others as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Shipped
Development

Successfully merging a pull request may close this issue.

5 participants