OpenUI5 version:
1.81.1 (older versions seem to be affected as well)
Browser/version (+device/version):
Tested on Chrome Version 84 for Windows and macOS.
URL (minimal example if possible):
https://codepen.io/Crossing/pen/abNWWXq?editors=1112
Steps to reproduce the problem:
Run the example above and check the console output.
What is the expected result?
The date object provided as input should not be changed (neither the reference nor the date's intrinsic value)
What happens instead?
It seems like a new Date instance holding another date value is referenced after calling .formatValue()
In the example "2020-08-16T22:59:00.000Z" vs. "2020-08-17T21:59:00.000Z"
Hi @Michi-4G ,
I have problem reproducing the described behaviour. For me the console output from the codepen snippet is:
"before" "2020-08-17T21:59:00.000Z"
"1 week ago"
"after" "2020-08-17T21:59:00.000Z"
Does it reproduce for you with the exact same codepen snippet?
Also in the coding of formatValue I don't see a place where we could be modifying the original value.
Regards,
Alexandar Mitsev
Hi Alexandar,
thanks for the fast response.
Yes, the codepen produces the output described above for me (and my co-workers).
As this might be relevant, I have added some output information about locale and timezone. For me the example outputs:

Does this help you?
Best,
Michael
Hi Michael,
Very strange behaviour indeed.
I've created an internal incident with number 2070281118 for further processing. The status of the issue will be updated here in GitHub.
Thanks and Regards,
Alexandar Mitsev
I have not investigated this in-depth, but the following statement is looking suspicious wrt the described issue: oJSDate = oDateUTC; in DateFormat.js#L2196.
However, I am lacking an understanding of the bigger context here and I am also not sure why this assignment is needed there at all.
I think the problem is with the cutDateFields method.
Depending on the chosen scale for relative date formats, this method seems to operator on the original Date and modifies some of its fields before calculating the time difference. I agree that this needs to be fixed. Formatters should not modify the input data.
Most helpful comment
I think the problem is with the cutDateFields method.
Depending on the chosen scale for relative date formats, this method seems to operator on the original
Dateand modifies some of its fields before calculating the time difference. I agree that this needs to be fixed. Formatters should not modify the input data.