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

[junglira]

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?

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.