Wrong System Time in overview

[aleeraser]

In the overview page, the displayed System Time is wrong.
e.g. if the time zone is CEST (+2) and the correct time is 18:00, the displayed time is 20:00.

I took a quick look at the code, I see that time is retrieved using date +%s:%z.
Running this in a shell, this indeed shows the correct time in epoch format (+%s), plus the time zone offset (%z).

The problem is that the utc_fake_now property is returned as a new Date(...) object.

cockpit/pkg/lib/serverTime.js

Lines 85 to 91 in 23701a5

	Object.defineProperty(self, 'utc_fake_now', {
	enumerable: true,
	get: function get() {
	const offset = time_offset + remote_offset;
	return new Date(offset + (new Date()).valueOf());
	}
	});

JavaScript's Date object tracks time in UTC internally, but typically accepts input and produces output in the local time of the computer it's running on.

For example:

let date = new Date();
console.log(date);
// Thu Jul 04 2024 12:25:45 GMT+0200 (Central European Summer Time)
console.log(date.valueOf());
// 1720088745200

Using the online epoch converter, it shows that 1720088745200 equals to:

Assuming that this timestamp is in milliseconds:
GMT: Thursday 4 July 2024 10:25:45.200
Your time zone: giovedì 4 luglio 2024 12:25:45.200 [GMT+02:00] DST

Which shows that new Date()'s output is indeed in the local time zone.

The problem is that later on, the Date object is formatted without taking into account the local time zone:

cockpit/pkg/lib/timeformat.ts

Line 28 in 23701a5

export const dateTime = (t: Time): string => formatter({ dateStyle: "medium", timeStyle: "short" }).format(t);

Which eventually results in the wrong format.

I see various ways to solve this:

• make the formatter aware of the local time zone using the TimeZone locale option
• return utc_fake_now property as UTC epoch time (i.e. using .valueOf()) and adjust the formatter
• calculate utc_fake_now as a UTC Date object stripped of the time zone

[martinpitt]

I can reproduce this, ouch! Thanks!

I don't know (or at least remember) the history around the utc_fake_now dance, but I'll have a look. We specifically call date on the server to get the server's idea of time and zone. We don't want JS to do any time zone calculation, so if timeZone: "UTC" does the right thing, that sounds like the most plausible option.

[aleeraser]

We specifically call date on the server to get the server's idea of time and zone

Agree, that makes sense in my opinion. And that's why I examined the code, as I thought I had something misconfigured on my side.

if timeZone: "UTC" does the right thing, that sounds like the most plausible option.

I stumbled upon this option while trying to figure out where the problem was. I'm not entirely sure if it solves the problem, but it looks promising.
Normally I'd try it, but I figured out that if someone already had a development setup in place, then it would have been quicker for the both of us :)

[martinpitt]

Fixed in #20724 . This regression happened in the latest release 320, it'll get fixed in Wednesday's 321. Thanks for the report!