Same Date(String) gives different results
up vote
0
down vote
favorite
For my WebApp I'm writting unit-tests using Jest and my dev environment is IntelliJ Ultimate 2018.1.
In my unit-tests I need to create Date() from a String. My problem is that when I share this unit-test with my colleague it's not working because the Date(String) is returning a different date (he's using the same dev environment).
For example, In my evironment, when I execute new Date("2018-05-12T19:00:00") I get Sat May 12 2018 19:00:00 GMT+0200 (Romance Summer time)
When my colleague executes exactly the same line of code, he gets Sat May 12 2018 21:00:00 GMT+0200 (Paris, Madrid (heure d'été))
When I add a Z at the end of the date, like new Date("2018-05-12T19:00:00Z") I get Sat May 12 2018 21:00:00 GMT+0200 (Romance Summer time) and he gets the same date with Sat May 12 2018 21:00:00 GMT+0200 (Paris, Madrid (heure d'été))
Why do we get this 2 hours differences when using new Date("2018-05-12T19:00:00") ? We are on the same timezone.
Thanks for your help!
javascript date timezone jestjs
edited Nov 7 at 7:52
skyboyer
2,69511027
asked Jul 26 at 11:44
sebastien
1,04841434
add a comment |
up vote
0
down vote
favorite
For my WebApp I'm writting unit-tests using Jest and my dev environment is IntelliJ Ultimate 2018.1.
In my unit-tests I need to create Date() from a String. My problem is that when I share this unit-test with my colleague it's not working because the Date(String) is returning a different date (he's using the same dev environment).
For example, In my evironment, when I execute new Date("2018-05-12T19:00:00") I get Sat May 12 2018 19:00:00 GMT+0200 (Romance Summer time)
When my colleague executes exactly the same line of code, he gets Sat May 12 2018 21:00:00 GMT+0200 (Paris, Madrid (heure d'été))
When I add a Z at the end of the date, like new Date("2018-05-12T19:00:00Z") I get Sat May 12 2018 21:00:00 GMT+0200 (Romance Summer time) and he gets the same date with Sat May 12 2018 21:00:00 GMT+0200 (Paris, Madrid (heure d'été))
Why do we get this 2 hours differences when using new Date("2018-05-12T19:00:00") ? We are on the same timezone.
Thanks for your help!
javascript date timezone jestjs
edited Nov 7 at 7:52
skyboyer
2,69511027
asked Jul 26 at 11:44
sebastien
1,04841434
1
Because the one browser interprets it as UTC and the other as the local timezone. But you found the solution already: put an explicit timezone on the string.
– Bergi
Jul 26 at 12:35
My unit-tests are executed by Jest in IntelliJ. In believe the runtime environment is Node.js and not the Browser. In addition, why the timezone is different? Romance Summer Time and Paris/Madrid are the same timezone.
– sebastien
Jul 26 at 13:08
I don't know Jest in particular, but it just shows that you and your colleague have different environments set up.
– Bergi
Jul 26 at 13:16
Probably should be closed, see Why does Date.parse give incorrect results? But I like the comments and answers. :-)
– RobG
Jul 27 at 0:29
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
For my WebApp I'm writting unit-tests using Jest and my dev environment is IntelliJ Ultimate 2018.1.
In my unit-tests I need to create Date() from a String. My problem is that when I share this unit-test with my colleague it's not working because the Date(String) is returning a different date (he's using the same dev environment).
For example, In my evironment, when I execute new Date("2018-05-12T19:00:00") I get Sat May 12 2018 19:00:00 GMT+0200 (Romance Summer time)
When my colleague executes exactly the same line of code, he gets Sat May 12 2018 21:00:00 GMT+0200 (Paris, Madrid (heure d'été))
When I add a Z at the end of the date, like new Date("2018-05-12T19:00:00Z") I get Sat May 12 2018 21:00:00 GMT+0200 (Romance Summer time) and he gets the same date with Sat May 12 2018 21:00:00 GMT+0200 (Paris, Madrid (heure d'été))
Why do we get this 2 hours differences when using new Date("2018-05-12T19:00:00") ? We are on the same timezone.
Thanks for your help!
javascript date timezone jestjs
edited Nov 7 at 7:52
skyboyer
2,69511027
asked Jul 26 at 11:44
sebastien
1,04841434
For my WebApp I'm writting unit-tests using Jest and my dev environment is IntelliJ Ultimate 2018.1.
In my unit-tests I need to create Date() from a String. My problem is that when I share this unit-test with my colleague it's not working because the Date(String) is returning a different date (he's using the same dev environment).
For example, In my evironment, when I execute new Date("2018-05-12T19:00:00") I get Sat May 12 2018 19:00:00 GMT+0200 (Romance Summer time)
When my colleague executes exactly the same line of code, he gets Sat May 12 2018 21:00:00 GMT+0200 (Paris, Madrid (heure d'été))
When I add a Z at the end of the date, like new Date("2018-05-12T19:00:00Z") I get Sat May 12 2018 21:00:00 GMT+0200 (Romance Summer time) and he gets the same date with Sat May 12 2018 21:00:00 GMT+0200 (Paris, Madrid (heure d'été))
Why do we get this 2 hours differences when using new Date("2018-05-12T19:00:00") ? We are on the same timezone.
Thanks for your help!
javascript date timezone jestjs
javascript date timezone jestjs
edited Nov 7 at 7:52
skyboyer
2,69511027
asked Jul 26 at 11:44
sebastien
1,04841434
edited Nov 7 at 7:52
skyboyer
2,69511027
asked Jul 26 at 11:44
sebastien
1,04841434
edited Nov 7 at 7:52
skyboyer
2,69511027
edited Nov 7 at 7:52
skyboyer
2,69511027
edited Nov 7 at 7:52
skyboyer
2,69511027
2,69511027
asked Jul 26 at 11:44
sebastien
1,04841434
asked Jul 26 at 11:44
sebastien
1,04841434
asked Jul 26 at 11:44
sebastien
1,04841434
1,04841434
1
Because the one browser interprets it as UTC and the other as the local timezone. But you found the solution already: put an explicit timezone on the string.
– Bergi
Jul 26 at 12:35
My unit-tests are executed by Jest in IntelliJ. In believe the runtime environment is Node.js and not the Browser. In addition, why the timezone is different? Romance Summer Time and Paris/Madrid are the same timezone.
– sebastien
Jul 26 at 13:08
I don't know Jest in particular, but it just shows that you and your colleague have different environments set up.
– Bergi
Jul 26 at 13:16
Probably should be closed, see Why does Date.parse give incorrect results? But I like the comments and answers. :-)
– RobG
Jul 27 at 0:29
add a comment |
1
Because the one browser interprets it as UTC and the other as the local timezone. But you found the solution already: put an explicit timezone on the string.
– Bergi
Jul 26 at 12:35
My unit-tests are executed by Jest in IntelliJ. In believe the runtime environment is Node.js and not the Browser. In addition, why the timezone is different? Romance Summer Time and Paris/Madrid are the same timezone.
– sebastien
Jul 26 at 13:08
I don't know Jest in particular, but it just shows that you and your colleague have different environments set up.
– Bergi
Jul 26 at 13:16
Probably should be closed, see Why does Date.parse give incorrect results? But I like the comments and answers. :-)
– RobG
Jul 27 at 0:29
1
1
Because the one browser interprets it as UTC and the other as the local timezone. But you found the solution already: put an explicit timezone on the string.
– Bergi
Jul 26 at 12:35
Because the one browser interprets it as UTC and the other as the local timezone. But you found the solution already: put an explicit timezone on the string.
– Bergi
Jul 26 at 12:35
My unit-tests are executed by Jest in IntelliJ. In believe the runtime environment is Node.js and not the Browser. In addition, why the timezone is different? Romance Summer Time and Paris/Madrid are the same timezone.
– sebastien
Jul 26 at 13:08
My unit-tests are executed by Jest in IntelliJ. In believe the runtime environment is Node.js and not the Browser. In addition, why the timezone is different? Romance Summer Time and Paris/Madrid are the same timezone.
– sebastien
Jul 26 at 13:08
I don't know Jest in particular, but it just shows that you and your colleague have different environments set up.
– Bergi
Jul 26 at 13:16
I don't know Jest in particular, but it just shows that you and your colleague have different environments set up.
– Bergi
Jul 26 at 13:16
Probably should be closed, see Why does Date.parse give incorrect results? But I like the comments and answers. :-)
– RobG
Jul 27 at 0:29
Probably should be closed, see Why does Date.parse give incorrect results? But I like the comments and answers. :-)
– RobG
Jul 27 at 0:29
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
The older ECMAScript 5.1 Spec says in §15.9.1.15:
... The value of an absent time zone offset is "Z".
That means, if you don't specify an offset, it will assume you meant UTC.
Note that since this is the opposite of what ISO-8601 says, this is behavior has been changed in ECMAScript 2015 (6.0), which says in §20.3.1.16:
... If the time zone offset is absent, the date-time is interpreted as a local time.
Thus, it would seem that your colleague is executing the code through an older version of the JavaScript engine. Your string is being interpreted as local time per the newer spec, and theirs is being interpreted as UTC per the older spec. Since you said this is all through Node.js, they should simply upgrade to a newer version of Node.js.
I blogged about this behavior some time ago, if you'd like more details.
If you want to be resilient to older environments, consider parsing the date string yourself or with a library. There are many to choose from. In general, many people do not trust the string parser that comes attached to the Date object because it has changed over the years, has some implementation-specific behaviors, and still does silly things like assuming whole dates like "2018-07-26" should be interpreted as UTC instead of local time like ISO 8601 specifies.
answered Jul 26 at 17:57
Matt Johnson
133k40269393
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
The older ECMAScript 5.1 Spec says in §15.9.1.15:
... The value of an absent time zone offset is "Z".
That means, if you don't specify an offset, it will assume you meant UTC.
Note that since this is the opposite of what ISO-8601 says, this is behavior has been changed in ECMAScript 2015 (6.0), which says in §20.3.1.16:
... If the time zone offset is absent, the date-time is interpreted as a local time.
Thus, it would seem that your colleague is executing the code through an older version of the JavaScript engine. Your string is being interpreted as local time per the newer spec, and theirs is being interpreted as UTC per the older spec. Since you said this is all through Node.js, they should simply upgrade to a newer version of Node.js.
I blogged about this behavior some time ago, if you'd like more details.
If you want to be resilient to older environments, consider parsing the date string yourself or with a library. There are many to choose from. In general, many people do not trust the string parser that comes attached to the Date object because it has changed over the years, has some implementation-specific behaviors, and still does silly things like assuming whole dates like "2018-07-26" should be interpreted as UTC instead of local time like ISO 8601 specifies.
answered Jul 26 at 17:57
Matt Johnson
133k40269393
add a comment |
up vote
0
down vote
The older ECMAScript 5.1 Spec says in §15.9.1.15:
... The value of an absent time zone offset is "Z".
That means, if you don't specify an offset, it will assume you meant UTC.
Note that since this is the opposite of what ISO-8601 says, this is behavior has been changed in ECMAScript 2015 (6.0), which says in §20.3.1.16:
... If the time zone offset is absent, the date-time is interpreted as a local time.
Thus, it would seem that your colleague is executing the code through an older version of the JavaScript engine. Your string is being interpreted as local time per the newer spec, and theirs is being interpreted as UTC per the older spec. Since you said this is all through Node.js, they should simply upgrade to a newer version of Node.js.
I blogged about this behavior some time ago, if you'd like more details.
If you want to be resilient to older environments, consider parsing the date string yourself or with a library. There are many to choose from. In general, many people do not trust the string parser that comes attached to the Date object because it has changed over the years, has some implementation-specific behaviors, and still does silly things like assuming whole dates like "2018-07-26" should be interpreted as UTC instead of local time like ISO 8601 specifies.
answered Jul 26 at 17:57
Matt Johnson
133k40269393
add a comment |
up vote
0
down vote
up vote
0
down vote
The older ECMAScript 5.1 Spec says in §15.9.1.15:
... The value of an absent time zone offset is "Z".
That means, if you don't specify an offset, it will assume you meant UTC.
Note that since this is the opposite of what ISO-8601 says, this is behavior has been changed in ECMAScript 2015 (6.0), which says in §20.3.1.16:
... If the time zone offset is absent, the date-time is interpreted as a local time.
Thus, it would seem that your colleague is executing the code through an older version of the JavaScript engine. Your string is being interpreted as local time per the newer spec, and theirs is being interpreted as UTC per the older spec. Since you said this is all through Node.js, they should simply upgrade to a newer version of Node.js.
I blogged about this behavior some time ago, if you'd like more details.
If you want to be resilient to older environments, consider parsing the date string yourself or with a library. There are many to choose from. In general, many people do not trust the string parser that comes attached to the Date object because it has changed over the years, has some implementation-specific behaviors, and still does silly things like assuming whole dates like "2018-07-26" should be interpreted as UTC instead of local time like ISO 8601 specifies.
answered Jul 26 at 17:57
Matt Johnson
133k40269393
The older ECMAScript 5.1 Spec says in §15.9.1.15:
... The value of an absent time zone offset is "Z".
That means, if you don't specify an offset, it will assume you meant UTC.
Note that since this is the opposite of what ISO-8601 says, this is behavior has been changed in ECMAScript 2015 (6.0), which says in §20.3.1.16:
... If the time zone offset is absent, the date-time is interpreted as a local time.
Thus, it would seem that your colleague is executing the code through an older version of the JavaScript engine. Your string is being interpreted as local time per the newer spec, and theirs is being interpreted as UTC per the older spec. Since you said this is all through Node.js, they should simply upgrade to a newer version of Node.js.
I blogged about this behavior some time ago, if you'd like more details.
If you want to be resilient to older environments, consider parsing the date string yourself or with a library. There are many to choose from. In general, many people do not trust the string parser that comes attached to the Date object because it has changed over the years, has some implementation-specific behaviors, and still does silly things like assuming whole dates like "2018-07-26" should be interpreted as UTC instead of local time like ISO 8601 specifies.
answered Jul 26 at 17:57
Matt Johnson
133k40269393
answered Jul 26 at 17:57
Matt Johnson
133k40269393
answered Jul 26 at 17:57
Matt Johnson
133k40269393
answered Jul 26 at 17:57
Matt Johnson
133k40269393
133k40269393
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f51538035%2fsame-datestring-gives-different-results%23new-answer', 'question_page');
}
);
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
Because the one browser interprets it as UTC and the other as the local timezone. But you found the solution already: put an explicit timezone on the string.
– Bergi
Jul 26 at 12:35
My unit-tests are executed by Jest in IntelliJ. In believe the runtime environment is Node.js and not the Browser. In addition, why the timezone is different? Romance Summer Time and Paris/Madrid are the same timezone.
– sebastien
Jul 26 at 13:08
I don't know Jest in particular, but it just shows that you and your colleague have different environments set up.
– Bergi
Jul 26 at 13:16
Probably should be closed, see Why does Date.parse give incorrect results? But I like the comments and answers. :-)
– RobG
Jul 27 at 0:29