Unable to correct time zone in Nextcloud with privacy features enabled in browser, and no way to specify a specific time zone to operate in if desired

[HollowedEmpire]

Steps to reproduce

1.) In Firefox, enable privacy.resistFingerprinting in about:config 2.) Go to to any app or Settings in Nextcloud, time zone is incorrect

Expected behaviour

Although Firefox will purposely report UTC with resist fingerprinting enabled, there should always be an option to manually set a time zone. There could be many cases where a user's environment could report an incorrect time zone, or the user may simply wish to operate in a specific time zone different from the system. Or in my case, I wish I didn't have to disable security features just to see things in the correct time zone.

Actual behaviour

My system reports a different time zone from the one I am in, and Nextcloud will gladly accept this incorrect information with no way to override it.

Server configuration detail

Operating system: Linux 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l

Webserver: Apache/2.4.38 (Raspbian) (fpm-fcgi)

Database: mysql 10.3.17

PHP version:

7.3.11-1~deb10u1 Modules loaded: Core, date, libxml, openssl, pcre, zlib, filter, hash, Reflection, SPL, session, sodium, standard, cgi-fcgi, mysqlnd, PDO, xml, apcu, bz2, calendar, ctype, curl, dom, mbstring, fileinfo, ftp, gd, gettext, gmp, iconv, igbinary, imagick, intl, json, exif, mysqli, pdo_mysql, pdo_pgsql, pdo_sqlite, pgsql, apc, posix, pspell, readline, redis, shmop, SimpleXML, sockets, sqlite3, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, wikidiff2, xmlreader, xmlwriter, xsl, zip, Phar, Zend OPcache

Nextcloud version: 17.0.2 - 17.0.2.1

Updated from an older Nextcloud/ownCloud or fresh install:

Where did you install Nextcloud from: unknown

Signing status

Array ( )

List of activated apps

``` Enabled: - activity: 2.10.1 - apporder: 0.9.0 - bookmarks: 2.3.4 - bruteforcesettings: 1.4.0 - calendar: 1.7.2 - checksum: 0.4.3 - cloud_federation_api: 1.0.0 - comments: 1.7.0 - contacts: 3.1.6 - cookbook: 0.5.7 - dav: 1.13.0 - deck: 0.7.0 - external: 3.4.1 - federatedfilesharing: 1.7.0 - federation: 1.7.0 - files: 1.12.0 - files_accesscontrol: 1.7.0 - files_automatedtagging: 1.7.0 - files_pdfviewer: 1.6.0 - files_rightclick: 0.15.1 - files_sharing: 1.9.0 - files_trashbin: 1.7.0 - files_versions: 1.10.0 - files_videoplayer: 1.6.0 - firstrunwizard: 2.6.0 - gallery: 18.4.0 - groupfolders: 5.0.5 - issuetemplate: 0.6.0 - logreader: 2.2.0 - lookup_server_connector: 1.5.0 - mail: 0.21.1 - maps: 0.1.2 - metadata: 0.10.0 - news: 14.1.2 - nextbackup: 19.12.1 - nextcloud_announcements: 1.6.0 - notes: 3.1.1 - notifications: 2.5.0 - oauth2: 1.5.0 - password_policy: 1.7.0 - passwords: 2020.1.0 - privacy: 1.1.0 - provisioning_api: 1.7.0 - ransomware_detection: 0.6.0 - ransomware_protection: 1.5.1 - recommendations: 0.5.0 - serverinfo: 1.7.0 - sharebymail: 1.7.0 - social: 0.2.101 - spreed: 7.0.2 - support: 1.0.1 - survey_client: 1.5.0 - systemtags: 1.7.0 - tasks: 0.11.3 - text: 1.1.1 - theming: 1.8.0 - timetracker: 0.0.39 - twofactor_backupcodes: 1.6.0 - twofactor_totp: 4.1.2 - twofactor_u2f: 5.0.2 - updatenotification: 1.7.0 - viewer: 1.2.0 - weather: 1.6.4 - workflowengine: 1.7.0 Disabled: - accessibility - admin_audit - encryption - files_antivirus - files_external - unsplash - user_ldap ```

Configuration (config/config.php)

``` { "instanceid": "***REMOVED SENSITIVE VALUE***", "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "paracosm.ddns.net" ], "datadirectory": "***REMOVED SENSITIVE VALUE***", "dbtype": "mysql", "version": "17.0.2.1", "overwrite.cli.url": "https:\/\/paracosm.ddns.net\/nextcloud", "overwriteprotocol": "https", "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbport": "", "dbtableprefix": "oc_", "mysql.utf8mb4": true, "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "installed": true, "maintenance": false, "twofactor_enforced": "false", "twofactor_enforced_groups": [ "admin" ], "twofactor_enforced_excluded_groups": [], "mail_smtpmode": "smtp", "mail_smtpsecure": "ssl", "mail_sendmailmode": "smtp", "memcache.loissue timezone cal": "\\OC\\Memcache\\APCu" } ```

Are you using external storage, if yes which one: local/smb/sftp/...

Are you using encryption:

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...

Client configuration

Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

Operating system: elementary OS 5.1 Hera

[y4my4my4m]

Just FYI, this is still an issue on browser with anti tracking.

[mwip]

Wouldn't it be possible to override the timezone using the tz set by the user?

[q-wertz]

As far as I know there is currently no possibility to set the timezone on the user side...

[webberian]

Well, the user/sysadmin can set the tz for the server, but the tz displayed in the "end-user" web interface cannot be changed, exactly. And this is why this bug occurs.

[q-wertz]

It would also make not very much sense (despite maybe for small "family & friends" installations) to use the server timezone...

[y4my4my4m]

It would also make not very much sense (despite maybe for small "family & friends" installations) to use the server timezone...

regardless, i've set my server TZ properly, server rebooted and all, still TZ properly set, HTTPS certificates created with the right timezone, enduser/browser side also have the exact same TZ, synced-properly to the second.

It still doesn't work as I don't think the issue really is about TZ but security problem with anti-tracking browsers.

[q-wertz]

regardless, i've set my server TZ properly, server rebooted and all, still TZ properly set, HTTPS certificates created with the right timezone, enduser/browser side also have the exact same TZ, synced-properly to the second.

It still doesn't work as I don't think the issue really is about TZ but security problem with anti-tracking browsers.

Not sure if I have an misunderstanding but I think you mix up different things...

The server timezone is of course important for certificates and all that stuff. But the discussion here is about the time which is shown to an user sitting in front of a browser on his Nextcloud interface. When he e.g. goes into his calendar, to polls and so on it makes sense to see all times in his current timezone which is apparently requested from the browser, which totally makes sense. (If he, sitting in e.g. Europe, sees the timezone of the server which is maybe in the US he will have a hard time calculating back and forth, so it is intended behavior to NOT see the server timezone but something specific to the user)

The problem is, that this information could be used for fingerprinting which is the reason why it is "disabled" by Firefox and it just reports the UTC timezone. Which results in the described "bug" and a feature request to set the user timezone in e.g. the personal settings (with options like: default -> browser reported TZ, UTC+1, ...)

[UPDATE] Just realized: The calendar even raises an warning and this setting is available (for the calendar app)

The automatic timezone detection determined your timezone to be UTC. This is most likely the result of security measures of your web browser. Please set your timezone manually in the calendar settings.

[ExceptionGit]

@skjnldsv, Can you recheck this issue?

labels ?: feature: settings and design title ?: Allow override timezone or Add setting "timezone" per user

If privacy.resistFingerprinting=true in firefox https://bugzilla.mozilla.org/show_bug.cgi?id=1330890 , then UTC always 0 and Nextcloud use incorrect date in WebUI for apps: files, activity, ... . Regional settings in http.../settings/user don't change this behavior and now no way to set/get correct date in WebUI. Anyway, date without timezone meta in WebUI could bring big problems for users.

[szaimen]

cc @nextcloud/server-triage is it feasible to introduce an additional timezone setting in Nextcloud in order to fix this?

[ghost]

This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.

[fabianski7]

✋

[ghost]

This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.

[q-wertz]

Could someone remove the tags so that the bot does not stale it every few weeks?

[ghost]

This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.

[SpcCw]

I confirm that this issue creates problems, especially when multiple devices are used as discrepancy between time in browser and on devices can create a lot of confusion.

Please remove the stale bot from this issue because it would be super nice to get it fixed someday.

[ghost]

This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.

[unixfox]

Bump, still relevant

[ghost]

This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.

[mwip]

Still relevant

[skjnldsv]

Damn, this one have been going for long. We don't have any priorities on this right now, if anyone to push that forward, we'll be happy to assist.

Sorry for the long response time everyone :disappointed:

[relaytt]

Any movement on this? The time is still incorrect with anti-tracking even with site exceptions.' I've also attempted to add my domain to "privacy.resistFingerprinting.exemptedDomains" in about:config, no luck.

Of reference: https://bugzilla.mozilla.org/show_bug.cgi?id=1635603#c12

[markus2330]

LibreWolf also has a spoofed time zone and privacy.resistFingerprinting.exemptedDomains even with privacy.resistFingerprinting.testGranularityMask=4 doesn't work.

In particular it is annoying for "Deck", as when I say something should be done "today" my partner sees it to be pending "tomorrow" (01:59 in the morning).

As Nextcloud already has a user setting for the language, having a setting for the timezone makes sense, especially if people in different time zones want to work together in Deck.

[abrahamparayil]

This is pretty important considering Nextcloud has applications like Deck, Calendar, Appointments etc. all of which are going to be affected by this.

[markus2330]

I just noticed that "nextcloud/index.php/settings/user/groupware" already contains a configuration setting called timezone (which probably only applies to the absence times). So probably no new setting needs to be introduced but only the configuration settings reorganized (groupware is not the place I would look for when I want to change my timezone or absence time) and their behavior implemented differently (that the timezone setting is actually used everywhere).

[Moilleadoir]

Disappointing to see ‘fixing completely wrong time’ as an ‘enhancement’.

[bcurran3]

I noticed that my calendar seemed off in the latter part of the day so I consoled into my NextCloud container and noticed date/time was set to UTC.

So I added the TZ: environment variable and rebuilt the container. Popped into console again and date displayed my local time and date now.

This was instigated by an all day calendar event that disappeared in the middle of the day. Weird thing though is that event is still not showing after the time change even though it's for today.

I've added a TEST all day event to my calendar for tomorrow and will check to see if it sticks around for the whole day local time or not.

[Transigence]

I'm also affected, severely affecting the usefulness of Deck and any other app that uses the profile time. We really need to be able to set our profile time zone instead of having our browser polled for it. That is just not a feasible approach with modern privacy-oriented browsers (or at least Firefox). It has been over three years now.

[Luk164]

I hit this issue today when I was trying to find out why nextcloud was reporting that last time cron ran was two hours ago.

[egor-yudkin]

It should be possible for a user to manually set the time zone for their profile, and not rely on what browser reports. It's a matter of user control of how they want their events and timestamps to be. And it's not only about privacy features in some browsers - there are other use cases. When I'm traveling I don't necessary want everything to be in my local time. The Calendar app has a setting for user time zone, and it displays this nice message to inform user what's happening. But why an App should handle this on it's own when this behavior is built in Nextcloud itself? It should be server level setting or at profile level.

[nbrucy]

Another use case is for shared agenda. It would be nice to have the agenda displayed in the timezone where the events are taking place (set when the agenda is shared) instead of the browser's timezone.

[czettnersandor]

I can confirm this is an issue, especially for people travelling often. I can set timezone on my Laptop, my phone figures it out by itself, but my calendar is always wrong in the browser, except when I'm in the UK, and it's winter (timezone is UTC)

[spcano01]

Same a bit frustrating.

[alexfulton]

Still running into this issue with privacy.resistFingerprinting on Firefox.

[karhima]

Oh that's the cause! I kept agreeing to the wrong time in polls and we couldn't figure out why that keeps happening - using LibreWolf where privacy.resistFingerprinting is enabled by default.