Closed Bug 1617258 Opened 5 years ago Closed 9 months ago

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

Categories

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

defect

Tracking

()

RESOLVED DUPLICATE of bug 1557650
Tracking Status
firefox73 --- affected

People

(Reporter: pedro.larouca, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: parity-chrome)

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

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!

Component: Untriaged → Networking
Flags: needinfo?(pedro.larouca)
OS: Unspecified → Windows 10
Product: Firefox → Core
Hardware: Unspecified → Desktop

(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

Flags: needinfo?(pedro.larouca)

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(valentin.gosu)

(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.

Flags: needinfo?(valentin.gosu) → needinfo?(pedro.larouca)

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.

Flags: needinfo?(pedro.larouca)
Component: Networking → NSPR
Keywords: parity-chrome
Product: Core → NSPR
QA Contact: jjones
Summary: set-cookie expire date is set as "Session" → Consider accepting 2020-03-24 12:54:40 AM +00:00 date format for PR_ParseTimeString
Version: 73 Branch → other

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(kaie)
Flags: needinfo?(kaie)
Priority: -- → P3

(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?

Flags: needinfo?(pedro.larouca)

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

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

(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

Flags: needinfo?(pedro.larouca)

(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.

(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.

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.

Flags: needinfo?(valentin.gosu)

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.

Component: NSPR → JavaScript Engine
Flags: needinfo?(valentin.gosu)
Product: NSPR → Core
QA Contact: jjones
Summary: Consider accepting 2020-03-24 12:54:40 AM +00:00 date format for PR_ParseTimeString → Consider accepting 2020-03-24 12:54:40 AM +00:00 date format for Date.parse
Version: other → Trunk
Blocks: 1274354

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

Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → S3

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

Status: NEW → RESOLVED
Closed: 9 months ago
Component: JavaScript Engine → JavaScript: Standard Library
Duplicate of bug: 1557650
OS: Windows 10 → All
Hardware: Desktop → All
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.