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

fromNow() gives inconsistent results between UTC & local mode #646

Closed
denchen opened this issue Jul 29, 2019 · 6 comments · Fixed by #649
Closed

fromNow() gives inconsistent results between UTC & local mode #646

denchen opened this issue Jul 29, 2019 · 6 comments · Fixed by #649
Labels

Comments

@denchen
Copy link

denchen commented Jul 29, 2019

Describe the bug
I've found a situation where fromNow() gives different results from MomentJS, and it gives different results depending on if you're in UTC mode or not.

Given the following:

let dutc = dayjs.utc(currentTimestamp37hrsAgo); // UNIX time for 37 hours before now
let mutc = moment.utc(currentTimestamp37hrsAgo);

console.log(`37 hours ago - DayJS (utc):     ${dutc.toISOString()}, fromNow(): ${dutc.fromNow()}`);
console.log(`37 hours ago - MomentJS (utc):  ${mutc.toISOString()}, fromNow(): ${mutc.fromNow()}`);

Output of the above:

37 hours ago - DayJS (utc):     2019-07-28T09:28:35.873Z, fromNow(): a day ago
37 hours ago - MomentJS (utc):  2019-07-28T09:28:35.873Z, fromNow(): 2 days ago

Here's a more extensive reproduction on Runkit

If it helps, my local timezone is PST (-07:00)

Expected behavior
It is my understanding that fromNow() should not "care" about timezones, and it's based strictly off of the difference in absolute time. fromNow() should give the same results, regardless of if we're using .utc() or not. I didn't check to see if toNow() also has the same problem, but I'd assume so.

Information

  • Day.js Version: 1.8.15
  • OS: MacOS 10.14.6
  • Browser: Chrome 75.0.3770.142
  • Time zone: -07:00 DST (Pacific Daylight Time)
@g1eny0ung
Copy link
Contributor

Runkit Clone

Here is my result and seems that it works as normal. I'm in UTC+8 (Beijing).

By viewing documents and code, I found moment.js will compare the local time in the fromNow() method. The code

But day.js won't do some special handling. The fromNow() method in day.js will call the diff() Internally. The diff method will use different comparison methods for different units.

So, I think maybe In some special cases, the fromNow() will have inconsistent results.

I can't completely guarantee that I am right. Maybe need some discussion?
@denchen @iamkun @xxyuk

@denchen
Copy link
Author

denchen commented Jul 30, 2019

@g1eny0ung

The difference is that your timezone is ahead of UTC (+8), and my timezone is behind UTC (-7). If I manually change my laptop's timezone to +8, fromNow() gives correct results, but if I change my timezone to any timezone after UTC, even -1, then I'll get different results.

However, there's another way to replicate the difference without changing your timezone. Instead of subtracting 37 hours, add 37 hours. In other words:

let currentTimestamp37hrsAgo = currentTimestamp + (37 * 60 * 60 * 1000);

Then you'll get the different results in your Beijing timezone.

37 hours ago - DayJS:           2019-08-01T07:04:28.958Z,  fromNow(): in 2 days
37 hours ago - MomentJS:        2019-08-01T07:04:28.958Z,  fromNow(): in 2 days
37 hours ago - DayJS (utc):     2019-08-01T07:04:28.958Z,  fromNow(): in a day
37 hours ago - MomentJS (utc):  2019-08-01T07:04:28.958Z,  fromNow(): in 2 days

@g1eny0ung
Copy link
Contributor

@denchen Got it. I will check the source code and try to find out where the problem lies.

@g1eny0ung
Copy link
Contributor

g1eny0ung commented Jul 31, 2019

@denchen #649

The problem is fromNow() method's internal diff method will calculate timezone offset when use dayjs.utc.

In order to maintain consistency, I use a boolean argument to avoid timezone comparison in relativeTime plugin change the fromNow() method to determine if this is in UTC mode.

@denchen
Copy link
Author

denchen commented Aug 27, 2019

Thank you for addressing this issue.

When can we expect a new release that includes this fix? A rough estimate would be fine.

@iamkun
Copy link
Owner

iamkun commented Aug 27, 2019

🎉 This issue has been resolved in version 1.8.16 🎉

The release is available on:

Your semantic-release bot 📦🚀

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

Successfully merging a pull request may close this issue.

3 participants