1617258 - Consider accepting 2020-03-24 12:54:40 AM +00:00 date format for Date.parse

Status: RESOLVED DUPLICATE of bug 1557650

(Core :: JavaScript: Standard Library, defect, P3)

Description

[pedrohex]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

using other browsers, the cookie expires date is set correctly. Firefox always set expires to "Session".

set-cookie: X_AUTH=eyJ...COOKIEDATA....xxx; expires=Fri, 21 Feb 2020 19:30:10 GMT; path=/

Actual results:

Expire date is ignored and uses expires = Session

Comment 1

[Daniel Bodea [:danibodea]]

I do not know whether this is intended or not so I am hoping that someone from the Networking component will triage this bug and have an opinion on the bug's description.

In the meantime, pedrohex, cand you answer some questions?

1. Did this issue occur on a Windows 10 machine and Firefox Release v73?
2. How exactly did you find this cookie expiration behavior? I need to reproduce it myself in order to confirm it and move it forward.

Thank you for your contribution!

Comment 2

[pedrohex]

(In reply to Bodea Daniel [:danibodea] from comment #1)

I do not know whether this is intended or not so I am hoping that someone from the Networking component will triage this bug and have an opinion on the bug's description.

In the meantime, pedrohex, cand you answer some questions?

1. Did this issue occur on a Windows 10 machine and Firefox Release v73?
2. How exactly did you find this cookie expiration behavior? I need to reproduce it myself in order to confirm it and move it forward.

Thank you for your contribution!

Sorry for the delay.

Regarding your questions :
1- V74 (latest at this date) continue to be possible to reproduce.
2- Meanwhile, I've found the problem:

Date.parse('2020-03-24 12:54:40 AM +00:00')

Firefox Returns : NaN
Other browsers Return: 1585011280000

My guess, cookie is set to session because of this parse error.

Hope it helps, thank you

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:valentin, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Valentin Gosu [:valentin] {{ PTO 2 - 12 April }}]

(In reply to pedrohex from comment #2)

2- Meanwhile, I've found the problem:

Date.parse('2020-03-24 12:54:40 AM +00:00')

Could you explain why you think that's the problem? It would be useful to know how you reached that conclusion.

(In reply to pedrohex from comment #0)

set-cookie: X_AUTH=eyJ...COOKIEDATA....xxx; expires=Fri, 21 Feb 2020 19:30:10 GMT; path=/

This date has a completely different format, and from what I can tell is not rejected.

Comment 5

[pedrohex]

The website is connecting through restful api. Every time a specific api call is made, a second variable named X_AUTH_EXPIRES, wich contains the value (eg) '2020-03-24 12:54:40 AM +00:00', is used to set the cookie again. When this occurs, cookie expire value is set to 'SESSION'. I could see this through webinspector.

I'm sure this is the problem and not a firefox bug, However, webkit+blink accept this date time format. I read the ECMA specification and, to be honest, I didn't find it clear to accept this format.

So.. not a bug but maybe adapting to the format is a useful suggestion.

Thanks for your attention. Regards.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:KaiE, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Kai Engert [:KaiE:]]

(In reply to pedrohex from comment #2)

Date.parse('2020-03-24 12:54:40 AM +00:00')

Firefox Returns : NaN
Other browsers Return: 1585011280000

Can you present any specification that allows time-of-day to be followed by a string like " AM +00:00" ?

Are you sure the other browser you used for comparison parses the date correctly?
The value 1585011280000 seems to refer to a different date:

Date(1585011280000)
"Tue Apr 14 2020 22:12:38 GMT+0200 (Central European Summer Time)"

Maybe parsing with the other browser simply runs into a failure scenario, and instead of returning a complete failure, they give you the result of a partial interpretation?

Comment 8

[Kai Engert [:KaiE:]]

We accept the string, if it isn't followed by " AM +00:00".

Date.parse('2020-03-24 12:54:40')
1585050880000

Comment 9

[pedrohex]

(In reply to Kai Engert (:KaiE:) from comment #7)

(In reply to pedrohex from comment #2)

Date.parse('2020-03-24 12:54:40 AM +00:00')

Firefox Returns : NaN
Other browsers Return: 1585011280000

Can you present any specification that allows time-of-day to be followed by a string like " AM +00:00" ?

Are you sure the other browser you used for comparison parses the date correctly?
The value 1585011280000 seems to refer to a different date:

Date(1585011280000)
"Tue Apr 14 2020 22:12:38 GMT+0200 (Central European Summer Time)"

Maybe parsing with the other browser simply runs into a failure scenario, and instead of returning a complete failure, they give you the result of a partial interpretation?

Hello Kai Engert,

You may try it with Chrome, date gets parsed correctly. My regional configurations are Western Europe indeed (Portugal), if you want to try the same scenario.

I wrote before that this is not a BUG. I found out what the problem was analyzing cookies from "a website". This site is creating a cookie with this format, which by the way I agree is invalid to ECMA standards. However, this format is the result of something like java.time.LocalDateTime or DateTime.Now() (aspcore.net). This thread only got here as a suggestion because other browsers can parse the format.

Thanks

Comment 10

[Kai Engert [:KaiE:]]

(In reply to Kai Engert (:KaiE:) from comment #7)

Are you sure the other browser you used for comparison parses the date correctly?
The value 1585011280000 seems to refer to a different date:

Date(1585011280000)
"Tue Apr 14 2020 22:12:38 GMT+0200 (Central European Summer Time)"

I made a mistake, "Date(number)" returns the current time.

I need to use "new Date(number)" to use the parameter. With that, we get the original input.
My theory about broken parsing was wrong.

Comment 11

[Kai Engert [:KaiE:]]

(In reply to pedrohex from comment #9)

However, this format is the result of something like java.time.LocalDateTime
or DateTime.Now() (aspcore.net).

I think we need to find an official specification for date formats that we should support.

java uses iso 8601 which doesn't allow this suffix apparently.

The examples given on https://docs.microsoft.com/en-us/dotnet/api/system.datetime.now?view=netframework-4.8 contain an "AM" suffix, but don't contain an "AM +offset" suffix.

I'd really like to see a specification of this date format, prior to deciding that we should support it.

Comment 12

[Kai Engert [:KaiE:]]

Valentin, I think PR_ParseTimeString isn't used when parsing date strings in JavaScript. I did a test with an NSPR C program. PR_ParseTimeString doesn't even accept the input "2020-03-24 12:54:40" (returns -1 as failure), which is an input that Date.parse() accepts.

This bug should be reassigned to the code module that implements JS date parsing.

Comment 13

[Valentin Gosu [:valentin] {{ PTO 2 - 12 April }}]

My bad. I thought based on the reporter's scenario that we use the same date parser. PR_ParseTimeString is used in Necko to parse the cookie date. Not exactly sure how their setup led to the bug happening.

In any case, moving to Core::JSEngine to maybe address the difference in parsing.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 15

[Vinny Diehl]

The patch for bug 1557650 fixes this, should be landing soon.