How to handle differing server and client times

[jshah4517]

What's the best way of handling when the server and client times differ? For example, if the clients clock is 5 mins behind, it would show 'in 5 minutes' instead of 'just now' which looks wrong.

I tried to enter a relative date like timeago('2016-06-10 12:12:12'), but after doing so it seems that the real-time updating no longer works. I believe this is because the diffSec function uses that date as the base to compare against rather than new Date().

// calculate the diff second between date to be formated an now date.
function diffSec(date, nowDate) {
  nowDate = nowDate ? toDate(nowDate) : new Date();
  return (nowDate - toDate(date)) / 1000;
}

If this isn't possible currently, perhaps if a relative date is entered, it should instead store an offset against new Date() and use that when working out the difference?

[hustcc]

That is realy a problem, the relative date can not solve the realtime render.

May be a time differ can solve it, but eveny client has different time differ.

[likerRr]

@jshah4517 if something is wrong with a client's time, it's his problem. The library shows relative diff to the clients time, not to UTC or GMT or something else.

As for ux you can show an alert to a client, that his clock is out of date and if the user doesn't fix it, the timers could work wrong. That's how it's done in JIRA.

[likerRr]

Ok, to solve the auto render problem you should return correct time from server, compare it with the client's time and add the difference to relative time which you use instantiating timeago. Will it help?

timeago('2016-06-10 12:12:12 + difference between server and client')

[jshah4517]

I had a go at a solution which makes the use of a relative date real-time too, the changes are hopefully fairly minimal. It seems to work quite nicely.
jshah4517@029754a

What do you think? I would be happy to submit a PR if it would seem like a worthwhile addition.

Edit: I should just mention, I only aimed to get it working for this case and haven't considered that perhaps people might want to use the relative date option without real-time updates, but perhaps this could be added as a third parameter?

[likerRr]

@jshah4517 thank you for trying solve this issue 😄

I think that function diffSec should compare difference between it's args. But after your changes it seems like the functions calculates difference between time and offset, which is not very consistent. So probably we should think on it more.

And you are right. If we want this feature then the changes should work both for real-time and for format.

@hustcc what do you think?

[jshah4517]

@likerRr Yes, you're right, especially if wanting to maintain how it currently works for relative dates.

I would probably add a new function offsetDate which works it out with the offset (set offset to 0 and enter relative date if not wanting real-time) and that gets fed in to the diffSec function.

I'll wait for @hustcc, but I'm happy to give it a go if it seems like a good suggestion.

[hustcc]

@likerRr @jshah4517
I have encountered this problem when I use timeago.js in other projects.

I think add one config namd offset is better then modify the function diffSec.

1. Keep the construction method unchanged.
2. Add one API setOffset(diff sec between server and client time, can be negative) on timeago instance, default is 0.
3. Sum the offset with the result of function diffSec.

The above is what I'm thinking, how do you think? The name of var and API need to confirm.

[jshah4517]

This works, but I think the offset could be calculated automatically. Would there ever be a need to have an offset which is different to what the difference between the relative date and client time is?

My thought was a boolean for the third param realtime, where it works out and stores the offset automatically based on the relative date. In terms of compatibility, I guess it would need to be true automatically if no relative date is entered, false by default otherwise. That would be my only hesitation with it, as it's potentially inconsistent, so maybe what you are proposing is safer?

[likerRr]

It could be automatically calculated, but i think a manual value is more "user" friendly way.

Imagine the app that renders how much time until sale starts in some online shop for different countries. Here we need to set offset manually for each of the country.

So i think the solution proposed by @hustcc is well enought.

[jshah4517]

OK I agree, that solution will be the most flexible. 👍

@hustcc would you like a PR? I might have time later this week.

[hustcc]

Waiting for your PR ^_^

[EvilJordan]

Aw, man. I got all excited someone else had solved this and then... no pull request :(

[aprilmintacpineda]

Please update the readme to include instructions as to how to use this feature.

[thedotedge]

No PR still? 😢