User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

In both my current profile and a new profile on Firefox 68.0.2 (Build 20190813150448) on macOS 10.14.6, I opened the Library window and looked at the most recent visit time in History and Bookmarks.

Nightly build 20190830215433 did not exhibit this issue, on either a profile created by the nightly build, or a profile that came from 68.

Actual results:

The timezone of the "Most Recent Visit" for History and Bookmarks shows in UTC. This also affects the time frames in the sidebar (i.e. Yesterday is from before 00:00 UTC of the current UTC date)

Expected results:

The timezone of the bookmarks and history "Most Recent Visit" should be in the system timezone.

Please can you go to Help -> Troubleshooting Information and copy the data from there (there's a button near the top), and paste it here?

Hi, we're not quite sure what is happening here, so here's a few suggestions of things that you can check / may prompt what's happening:

• Have you double-checked the timezone and region of the computer you're using?
• Is it possible that the timezone might have changed temporarily?
• Could you provide a screenshot showing some of the times in the library and the time on the computer?

• I've double checked it, and it's set to the correct timezone and region (UTC-7), en_US.

• Not likely, as the time in the menu bar and the time in the library window show different times even for sites visited within the past few seconds.

• Screenshot attached.

Could you please check Places database integrity from about:support, and report results? Let's exclude corruption first of all.
Second, could you please execute "new Date().getTimezoneOffset()" in the javascript console? What's the result?

new Date().getTimezoneOffset()
0

Which seems a little bit... off.

this seems to confirm there's some platform problem here, we are getting wrong timezone data from the OS.

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

For more information, please visit auto_nag documentation.

I'm not sure where to move this bug, we are just using common platform calls to get the time, we get the time in the wrong time zone, could be somewhere in javascript world or the platform integration code.
Moving to Core :: General for now in the hope someone has an idea of which code may be closer to the issue.

Blame for lines in getTimezoneOffset's implementation are all in SpiderMonkey so I'll move this bug there.

The trouble shooting information provided in comment #2 show that the resist finger printing option is enabled, which means this is bug 1364261.