fix bz #69316 FastHttpDateFormat - getCurrentDate() returns inaccurate result#751
Conversation
check whether cached date and current date are in same second.
|
This looks to be more precise (so maybe ?) but the start of processing and/or actual completion of requests on two separate connections is a rather random affair timing wise. Anything can happen ... So what is then the benefit of the extra precision of the date header ? |
markt-asf
left a comment
There was a problem hiding this comment.
In addition to the specific comments on the code there is the more general question of whether we want to fix this issue at all. HTimestamps might be out by up to 1s (plus the system clock skew) with the current code. How much of a problem does that cause?
There is a performance cost of fixing this. It is only ~1ns per request so almost certainly not an issue but I think we need to explicitly make any such decisions else we'll keep doing this and lots of little performance impacts will add up over time.
remove unused comment
Follows markt-asf suggestion, change internal currentDateGenerated unit from ms to sec.
|
The code looks good to me but I'd still like to see an answer to Rémy's question above before we decide whether to merge this PR. |
|
It it doesn't much perform worse, I'm fine with it. |
|
OK. I'll merge this then fix the missing ALv2 header and any other issues before porting it to the other versions. |
FastHttpDateFormat#getCurrentDate() returns same string for two different second datetime.
For following date:
1st:1726041009036, Wed, 11 Sep 2024 07:50:09 GMT
2nd:1726041009940, Wed, 11 Sep 2024 07:50:09 GMT
1st:1726041011501, Wed, 11 Sep 2024 07:50:11 GMT
2nd:1726041012101, Wed, 11 Sep 2024 07:50:11 GMT --it is incorrect.
Fix: check whether cached date and current date are in same second.