Javascript Dates working weird (when converting milliseconds to seconds )

Question

I have future date and now date. Both of this dates are always in same day but with just different hours. My goal is to get the difference of seconds between the future date and now date as my countdown value for a timer. The problem is when I calculate I'm getting inaccurate results.

In my research formula of converting milliseconds to seconds is millis / 1000.0 but non of this returns accurate countdown result;

My code

let now = (new Date().getTime() / 1000.0);
let futureDate = (new Date('2022-04-01T17:41:47.000Z').getTime() / 1000.0);

let difference;
difference = (futureDate - now); // not accurate
difference = parseInt(difference, 10); // not accurate

I would like the solution to work normal on all timezones and to inherit local system timezone instead of future date timezone.

Any help will be appreciated so much.

What do you mean by "not accurate"? What is the future date you have? What is the result you expect? What is the result you get instead? — VLAZ, Apr 01 '22 at 06:05
@VLAZ I'm expecting seconds to represent accurate difference between future date and now date. — James Mwase, Apr 01 '22 at 06:08
[I cannot reproduce it](https://jsbin.com/vusigib/1/edit?js,console). What is the result *you* get? And what should it be instead? You've not explain what is wrong here. — VLAZ, Apr 01 '22 at 06:12
@VLAZ I'm getting extra hour(s) or lets say extra time on the difference which is wrong. — James Mwase, Apr 01 '22 at 06:14
Are you sure it's not because of local time difference? If you're in, for example, a +04:00 timezone and *right now* it's 10:00 for you, the difference to 17:41+00:00 is going to be 11 hours and 41 minutes due to the time zone shift rather than 7 hours and 41 minutes. https://jsbin.com/koxesop/1/edit?js,console — VLAZ, Apr 01 '22 at 06:17
@VLAZ is there anyway to normalize this. Because when the code works it is supposed to work normally on any timezone. — James Mwase, Apr 01 '22 at 06:28
Depends on what you actually want. Do you want to compare to 17:41 *local time*? — VLAZ, Apr 01 '22 at 06:31
@VLAZ yes. The time should be normal based on system local time. — James Mwase, Apr 01 '22 at 06:33
Then removing the `Z` in the future date (or the time zone offset if it's in the form of `+HH:MM`) would be enough. It would be treated as local time. — VLAZ, Apr 01 '22 at 06:35
@VLAZ Ok man so just to be sure. Future date should be like `2022-04-01T17:41:47.000` right? — James Mwase, Apr 01 '22 at 06:37
Correct - if you do not mention the timezone, then it is going to be treated as local. — VLAZ, Apr 01 '22 at 06:49

enoeht · Answer 1 · 2022-04-01T22:18:46.383

0

I want to check if you know that date formats like "0000-00-00T00:00:00.000Z" are always recognized as universal time (UK time).

Try using +HH:MM instead of the last Z character.

For example, if you are in the US East, it would be "2022-04-01T17:41:47.000-05:00".

edited Apr 01 '22 at 22:18

answered Apr 01 '22 at 06:17

enoeht

241
2
9

No man I do not know. But let me try your solution right now. – James Mwase Apr 01 '22 at 06:18
2

Universal time is not UK time. UK uses UTC for half the year and last week it switched to BST - British Summer Time which is an hour ahead of UTC. – VLAZ Apr 01 '22 at 06:19
@VLAZ You right. I skipped too many. – enoeht Apr 01 '22 at 06:22
@RobG It's just a string format example. See the -5 in the bottom row. – enoeht Apr 01 '22 at 14:14

n-- · Accepted Answer · 2022-04-01T23:23:54.890

0

You should add the system timezone, like this:

let date = new Date('2022-04-01T17:41:47.000Z');
let now = new Date().getTime() / 1000.0;
let futureDate = (date.getTime() + date.getTimezoneOffset() * 60000) / 1000.0;

let difference;
difference = (futureDate - now); // not accurate
difference = parseInt(difference, 10); // not accurate
console.log(difference);

edited Apr 01 '22 at 23:23

answered Apr 01 '22 at 06:31

n--

3,563
4
9

This makes the assumption that the timezone offset for two essentially random dates will be the same. There's a good chance that in places that observe daylight saving that that assumption is wrong, and in places that don't, it will may be wrong over historical changes in offset. – RobG Apr 01 '22 at 10:34
@RobG Actually this is exactly the functionality I want. Otherwise if the timezones are not the same then the difference result is always wrong. – James Mwase Apr 01 '22 at 20:43
@Muje—so if `new Date()` returns a time for when local DST applies but the timestamp is for a time when it doesn't, you're happy with that? I can't fathom the reason for a requirement for essentially random offsets where a timestamp with offset is parsed to a different value depending on when and where it's parsed. That's normally the problem, not the solution. :-/ – RobG Apr 01 '22 at 22:35
@RobG You are right about DST, I fixed that, as for timezone offset, that is lost forever as there is no way to know it from an ISO timestamp. – n-- Apr 01 '22 at 23:25
The timestamp does have an offset, Z. By removing it and assuming a random local offset you're effectively randomising the moment in time that the original timestamp represents. If you're happy with that, fine, post an answer that "fixes" the DST issue (because this answer doesn't) and explain why you're using that method. Otherwise, this isn't a particularly useful question or answer. – RobG Apr 02 '22 at 02:32
@RobG Can you reason please about `(because this answer doesn't)`? That method is used as a form of manipulating with date object, "removing the Z" as you said is not really a proper way to deal with dates. – n-- Apr 02 '22 at 07:43
@RobG My hosting is in Europe. That is why the timezone for future date is like that. The time from backend is manipulated a bit then it is returned as a response to mobile app. So it is strictly important that the backend time inherits local system timezone to produce exact countdown seconds until future date. The countdown result is parsed to a Timer component for tracking remaining time. I have react native for frontend. – James Mwase Apr 02 '22 at 11:15

score -2 · Answer 3 · answered Apr 01 '22 at 10:48

The timestamp '2022-04-01T17:41:47.000Z' will be parsed as offset +0 (aka UTC or GMT) due to the trailing "Z", denoting a +0 offset. The difference between now and then in milliseconds is:

let diff = new Date('2022-04-01T17:41:47.000Z') - Date.now();

where a negative value for diff means the timestamp is in the past. To convert the difference to seconds, divide the result by 1,000.

If run at exactly the same time, the value for diff will be the same regardless of system settings for local offset (allowing for clock accuracy of course).

For the timestamp to be parsed as local, remove the Z:

let diff = new Date('2022-04-01T17:41:47.000') - Date.now();

However, that shifts the instant in time represented by the timestamp by the local offset, so will return a different value for diff for each system with a different offset. That doesn't seem like a sensible thing to do given the timestamp has an offset and so is intended to represent a single instant in time, not one of many different instants (as many as there are different offsets, perhaps hundreds if historical offsets are included) depending on the host offset.

Javascript Dates working weird (when converting milliseconds to seconds )

3 Answers3