bug 1567862 was duped here, but page refresh doesn't fix the problems in bug 1567862, unlike what's reported here in comment #0...

The date-time state is stored in the global variable js::DateTimeInfo::instance in DateTime.cpp and we check for system time zone changes in Realm::init and JSRuntime::init, so unless running new Date().toString() and devtools inspection via plain new Date() is executed in separate processes, which may have different js::DateTimeInfo::instance objects, both should return the same output. (I don't know how devtools formats built-in types, but https://searchfox.org/mozilla-central/source/devtools/client/debugger/packages/devtools-reps/src/reps/date-time.js looks like a possible candidate and there the normal toString function is simply called.)

I'm really sorry, but I read and re-read comment #4 multiple times and I do not understand how it relates to whether page refreshes fix the issue. I don't know whether Realm or JSRuntime correspond to page instances (and a refresh causes them to be torn down and new ones constructed) or not. Is this something that changed since the issue was filed?

As it is, my confusion is that comment #0 suggests that a simple page refresh fixes this, and that new page loads are not affected, but that's not what I'm seeing. I also think us never updating the timezone for the parent or content processes once the browser has started is a more serious issue than it not being updated for individual pages during the lifetime of the document/page. If that's a regression, we should probably figure out what caused it.

Realm corresponds to a global object, an overview is documented here.

I can reproduce the devtools issue from bug 1567862 locally (under Ubuntu) and it does look like devtools is running in a difference process with its own js::DateTimeInfo instance.

STR:

• Set time zone to CEST, open Firefox and a web page
• Open devtools, execute [new Date(), new Date().toString()]
• Both time zone strings should match
• Set time tone to BST, reload page, but leave devtools open
• Execute [new Date(), new Date().toString()]
• new Date() should display CEST, where new Date().toString() should use BST
• Open and close devtools (I've used ctrl+shift+i, not sure if there's a difference how it's closed and opened)
• Execute [new Date(), new Date().toString()] again
• Both time zone strings should now match

So, if devtools is running in a different process and that process never creates a new Realm, the system time zone is never rechecked and continues using the old one. But as soon as the devtools process creates a new Realm, apparently opening and closing devtools does that, the system time zone is revalidated and the new time zone is used.

There's one additional wrinkle, maybe the C time.h functions don't get the current system time zone rightaway on MacOS. If anyone with a Mac can try if this test program prints the new time zone offset after changing the system time zone, it'd be much appreciated.

OK. I think I understand a little more now. I left out some context in bug 1567862 which I probably shouldn't have done. That is, I had opened irccloud and slack in the pre-timezone-change firefox instance, and they also used the "wrong" timezone, and continued doing so even when I closed the tab and navigated to the site again or refreshed those pages. The regular devtools console evaluating in those contexts produced "wrong" results too (though perhaps not the inconsistent toString() and "pretty" output, I don't recall). Perhaps the realms are being kept alive by service workers, or for other reasons, and that leads to the tz info not being updated?

(In reply to André Bargull [:anba] from comment #7)

There's one additional wrinkle, maybe the C time.h functions don't get the current system time zone rightaway on MacOS. If anyone with a Mac can try if this test program prints the new time zone offset after changing the system time zone, it'd be much appreciated.

So to be clear, I compiled with clang++ --std=c++11 filename.cpp, ran the program, then changed the timezone in system prefs, then hit enter/return on the commandline, and a changed value was printed (and so on every time I changed timezone + hit enter). Does that clarify?

(In reply to :Gijs (he/him) from comment #8)

OK. I think I understand a little more now. I left out some context in bug 1567862 which I probably shouldn't have done. That is, I had opened irccloud and slack in the pre-timezone-change firefox instance, and they also used the "wrong" timezone, and continued doing so even when I closed the tab and navigated to the site again or refreshed those pages. The regular devtools console evaluating in those contexts produced "wrong" results too (though perhaps not the inconsistent toString() and "pretty" output, I don't recall). Perhaps the realms are being kept alive by service workers, or for other reasons, and that leads to the tz info not being updated?

Hmm, maybe? Do service workers store a complete global object in memory?

So to be clear, I compiled with clang++ --std=c++11 filename.cpp, ran the program, then changed the timezone in system prefs, then hit enter/return on the commandline, and a changed value was printed (and so on every time I changed timezone + hit enter). Does that clarify?

Thanks! Great, that does sound everything works correctly as far as system time zone changes and time.h functions are concerned.

Is this now fixed in the very latest Nightly?

I've tested against 103 and the timezone updates as expected in the provided test file.