Calendar: Issues with jstz

[daniellukaszgmailcom]

Steps to reproduce

1. Open the calendar on firefox: .../index.php/apps/calendar/ or .../index.php/apps/calendar

Expected behaviour

It should load the calendar app with my events on correct timezone

Actual behaviour

Calendar is loading with wrong timezone and message say:
"You are in an unknown timezone (Etc/GMT-1), falling back to UTC"

Server configuration

Operating system: raspbian 4.9.24-v7+
Web server: apache 2.4.10 (Raspbian)
Database: mysql 5.5.54-0+deb8u1
PHP version: 5.6.30-0+deb8u1
Server version: 12.0.0.29
Calendar version: 1.5.3
Updated from an older installed version or fresh install: fresh (fresh installation was performed because of this issue)
Signing status (ownCloud/Nextcloud 9.0 and above): No errors have been found.

List of activated apps:
Enabled:

• activity: 2.5.2
• admin_audit: 1.2.0
• audioplayer: 2.0.1
• bookmarks: 0.10.0
• bruteforcesettings: 1.0.2
• calendar: 1.5.3
• checksum: 0.3.4
• comments: 1.2.0
• contacts: 1.5.3
• dav: 1.3.0
• encryption: 1.6.0
• external: 2.0.3
• federatedfilesharing: 1.2.0
• federation: 1.2.0
• files: 1.7.2
• files_accesscontrol: 1.2.4
• files_external: 1.3.0
• files_pdfviewer: 1.1.1
• files_reader: 1.0.4
• files_sharing: 1.4.0
• files_snapshots: 0.1.1
• files_texteditor: 2.4.1
• files_trashbin: 1.2.0
• files_versions: 1.5.0
• files_videoplayer: 1.1.0
• firstrunwizard: 2.1
• gallery: 17.0.0
• gpxedit: 0.0.6
• groupfolders: 1.0.2
• keeweb: 0.4.0
• logreader: 2.0.0
• lookup_server_connector: 1.0.0
• mail: 0.6.4
• news: 11.0.5
• nextcloud_announcements: 1.1
• notes: 2.2.0
• notifications: 2.0.0
• oauth2: 1.0.5
• onlyoffice: 1.0.4
• ownbackup: 17.5.0
• ownpad: 0.5.10
• password_policy: 1.2.2
• previewgenerator: 1.0.6
• provisioning_api: 1.2.0
• serverinfo: 1.2.0
• sharebymail: 1.2.0
• socialsharing_email: 1.0.1
• survey_client: 1.0.0
• systemtags: 1.2.0
• tasks: 0.9.5
• theming: 1.3.0
• twofactor_backupcodes: 1.1.1
• twofactor_totp: 1.3.0
• updatenotification: 1.2.0
• workflowengine: 1.2.0
  Disabled:
• gpxpod
• richdocuments
• socialsharing_diaspora
• user_external
• user_ldap
• weather

Nextcloud configuration:
{
"system": {
"instanceid": "REMOVED SENSITIVE VALUE",
"passwordsalt": "REMOVED SENSITIVE VALUE",
"secret": "REMOVED SENSITIVE VALUE",
"trusted_domains": [
"REMOVED SENSITIVE VALUE"
],
"datadirectory": "REMOVED SENSITIVE VALUE",
"overwrite.cli.url": "REMOVED SENSITIVE VALUE",
"dbtype": "mysql",
"version": "12.0.0.29",
"dbname": "REMOVED SENSITIVE VALUE",
"dbhost": "localhost",
"dbport": "",
"dbtableprefix": "REMOVED SENSITIVE VALUE",
"dbuser": "REMOVED SENSITIVE VALUE",
"dbpassword": "REMOVED SENSITIVE VALUE",
"installed": true,
"mail_smtpmode": "sendmail",
"mail_smtpauthtype": "LOGIN",
"mail_domain": "REMOVED SENSITIVE VALUE",
"mail_from_address": "REMOVED SENSITIVE VALUE",
"mysql.utf8mb4": true,
"maintenance": false,
"logtimezone": "Europe\/Berlin"
}
}

Are you using external storage, if yes which one: no
Are you using encryption: yes
Are you using an external user-backend, if yes which one: no

Client configuration

Browser: firefox 53.03
Operating system: Linux Mint
CalDAV-clients: none

Logs

Web server error log: without issues (2xx/3xx)

Log file (data/nextcloud.log): without issues

Browser log: without issues (2xx/3xx)

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[daniellukaszgmailcom]

I found, that on my chromium-browser, vivaldi and firefox for android problem is not visible. So, the issue is visible only on my PC firefox 53.03 browser. Any hint to solve it?

[georgehrke]

What's the system timezone set up in your Mint system?

[daniellukaszgmailcom]

date +%Z indicate me this timezone: CEST
(date +'%:z %Z' gave me: +02:00 CEST)
however, chromium and vivaldi are used on the same computer

[georgehrke]

What timezone does https://pellepim.bitbucket.io/jstz/ display?

[daniellukaszgmailcom]

Etc/GMT-1

[daniellukaszgmailcom]

chromium shows Europe/Berlin

[georgehrke]

Do you mind reporting a bug over at the jstz repo? It's the library we use for determining a user's timezone.

[daniellukaszgmailcom]

ok, I will try ;) thanks for that!

[georgehrke]

thx :)

[daniellukaszgmailcom]

This is familiar: https://bitbucket.org/pellepim/jstimezonedetect/issues/164/buenos-aires-timezone-incorrectly

[shtrom]

Same issue with UTC+1000 (AEST) being reported as Etc/GMT-10 by https://pellepim.bitbucket.io/jstz/ with Firefox 53.0.3. @daniellukaszgmailcom, did you end up reporting an issue to them? What is the issue number?

Edit: Ah, nevermind, I was assuming a Github issue, not Bitbucket.

[pablow1422]

Hi. Just a question: Is that repo (jstz) still active? Latest commits are from 2015 and nobody replied the bug section in months.

[daniellukaszgmailcom]

this is a good question ;)
@georgehrke maybe the Etc/GMT-XX is an expected value? According pablow1422 information - it seems, that it is not modified since 2015...

[shtrom]

On Thu 15 Jun 2017 at 02:55:38 -0700, daniellukaszgmailcom wrote:

this is a good question ;)
@georgehrke maybe the Etc/GMT-XX is an expected value? According pablow1422 information - it seems, that it is not modified since 2015...

That said, the issue seems to show up consistently with Firefox 53.0.3
(but not on Mac OS X; I just tested and it works fine, both in Calendar
and the jstz site).

Note that in my previous comment above (FF 53.0.3 on ArchLinux x86_64),
the Etc/GMT-10 was widely incorrect, as it should at least be GMT +
10.

--
Olivier Mehani [e-mail]
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.

[pablow1422]

Ok, now I'm having issues with Google Chrome (latest stable) in Ubuntu 17.04. The time zone is detected as "America/Buenos_Aires" but Calendar changes it to UTC. The jstz repo is evidently dead so it can't be solved from "upstream". Are there any other methods from which the timezone can be obtained?

[georgehrke]

The jstz repo is evidently dead so it can't be solved from "upstream".

I pinged the maintainer to ask about the current status of the library.

Are there any other methods from which the timezone can be obtained?

At the moment we heavily rely on jsTz. If it turns out its unmaintained and there is no maintained fork of it, we will have to find a different solution.

1. Look for other libraries that do the same job
2. Use location again (we did this years ago and we got a lot of bugreports with people asking us why Nextcloud asks for their location, the method to determine the timezone based on the location was also quite error prone)
3. let the user choose from a list
4. create a fork of jstz on our own and maintain (really not a fan of this idea)

[wrexroad]

OK, so I looked at the jstz code a bit and found the problem. The first thing that determine() tries to do is nothing at all. It gets the timezone key from the browser by calling Intl.DateTimeFormat().resolvedOptions().timeZone. If that works, simply returns that value with no validation (other than it being truthy).

Setting my computers timezone to America/Argentina/Buenos_Aires I get the following result in the web console of Firefox 53.0.3 / 54.0:

Intl.DateTimeFormat().resolvedOptions().timeZone
"Etc/GMT+3"

Interestingly, Chrome is arguably worse because calling this function throws an uncaught error

Uncaught RangeError: Unsupported time zone specified undefined(…)

and prevents determine() from doing anything.

This seems like an easy enough fix, just remove the Intl api call all together and let the library do its thing.

If the developer doesn't respond soon, I would be willing to fork/maintain this library for the foreseeable future. Although, I think it might be best if Nextcloud was willing to bring the fork in as a sub project and let me be a maintainer. That way if something happens to me in the future there is an easier path moving forward. But if that is not desirable, I would be happy to just fork it under my own name.

[georgehrke]

I pinged the maintainer to ask about the current status of the library.

It's maintained "very sporadically" :/ (https://twitter.com/pellepim/status/886830163480150016)

[djmwj]

My Calendar also does not appear to show the correct timezone. IMHO the best option would be to at least give the option for the user to specify the calendar timezone explicitly vice an automated process. This is georgehrke's option 3. At least make this an option in the preferences, I travel too much, and rely on a consistent and reliable calendar. Thanks for all the great work.

[Hakuyume]

I have same issue.
In my case, "Etc/GMT-9" was detected (my timezone is UTC+9).

I wrote a simple patch to fix this issue.
https://github.com/Hakuyume/nextcloud-calendar/commit/ea1c314e6c4e925d440a64d2ca0d52d9a18812e2
This patch overrides Intl.DateTimeFormat and lets jstz use another solver.

[Hakuyume]

If this page shows proper timezone, my patch will work well. This is a patched version of jstz's demo.

[PeGa]

@Hakuyume the page you just referenced shows the proper timezone. I wanted to apply your code to the calendar app on my live Nextcloud 12.0.1 installation, but I'm unable to find the file containing the offending code.

Should I apply the patch to a recent (1.5.3) build and re-install it from filesystem?

[Hakuyume]

@PeGa What's the version of your calender app? The corresponding code has existed since v1.4.1.

[Hakuyume]

@PeGa Please note that tarballs in Releases do not contain original source codes because they were js compiled. The offending code was compiled as calendar/js/public/app.js and calendar/js/public/app.min.js.

[PeGa]

Thanks for the hint @Hakuyume .

According to CHANGELOG.md in the app's install directory, the current version is

## 1.5.3 - 2017-05-21

Thank you!

[shtrom]

If this page shows proper timezone, my patch will work well. This is a patched version of jstz's demo.

Works for me, too (FF 55.0.3 64bit on OS X).

[shtrom]

The test page works for FF 55.0.2 64 bit on ArchLinux.

The timezone on the calendar (v1.5.3) is still off (Etc/GMT-10) with this one. It was correct on on the Mac from my comment above (note the different patch version for Firefox).

[shtrom]

The issue remains with FF 55.0.3 64 bit on ArchLinux even though the test page works as expected.

[Hakuyume]

The issue remains with FF 55.0.3 64 bit on ArchLinux even though the test page works as expected.

That's strange... My Firefox 55.0.2 on ArchLinux was fixed by the patch.

[georgehrke]

@Hakuyume Thx for looking into this!

Do you mind sending a pull request upstream to the jstz library to fix it? :)

[Hakuyume]

@georgehrke
Now I'm searching Mozilla's bug reports because it seems a bug of Intl. I will send a PR if I can solve it.
Anyway, I think this issue should be solved in upstream (Intl or jstz). (This is the reason why I didn't make a PR for my patch).

[djmwj]

Thanks for looking into this, the test page works for me as well. (Arch FF55.0.3 (64-bit)) That being said, it would still be great to manually select my timezone if i want to see the calendar from a specific or constant time zone perspective. This functionality was there until recently. Thanks again.

[shtrom]

That's strange... My Firefox 55.0.2 on ArchLinux was fixed by the patch.

Yeah, not mine 🤔 Neither 55.0.2 nor 55.0.3 on Arch are fixed, and that's on the same Nextcloud that got fixed on 55.0.3 on OS X. I tried hard refreshing the page to clear the cache, but that apparently was not sufficient.

Is there any particular storage that might still be caching old code?

[shtrom]

Issue still here with 1.5.4 on 55.0.3/Arch.

Is there any particular file that I should check on my install (from the browser) to make sure I have the patched version?

[Hakuyume]

@shtrom Did you build the calendar app? Please make sure calendar/js/public/app.min.js is updated on your server.

[shtrom]

No, just upgraded from the app store. What should I look for specifically in that file?

[Hakuyume]

If the patched version was installed successfully, calender/js/public/app.js should have these lines:

   5689                 var dateTimeFormat = Intl.DateTimeFormat;
   5690                 Intl.DateTimeFormat = function () {
   5691                         return { resolvedOptions: function resolvedOptions() {
   5692                                         return {};
   5693                                 } };
   5694                 };
   5695                 var tz = jstz.determine();
   5696                 Intl.DateTimeFormat = dateTimeFormat; 

[shtrom]

That would be the issue: it's not there 🤔

apps/calendar/js/public$ grep -i version ../../appinfo/info.xml 
<?xml version="1.0"?>
        <version>1.5.4</version>
                <nextcloud min-version="11" max-version="13" />
apps/calendar/js/public$ grep -l Intl *.js
vendor.ie.js
vendor.ie.min.js
vendor.js
vendor.min.js
apps/calendar/js/public$ ls -l
total 17176
-rw-r--r--  1 www  daemon   350344 Sep 13 02:40 app.js
-rw-r--r--  1 www  daemon   248091 Sep 13 02:40 app.min.js
-rw-r--r--  1 www  daemon   161736 Sep 13 02:40 app.min.js.map
-rw-r--r--  1 www  daemon  2732080 Sep 13 02:40 vendor.ie.js
-rw-r--r--  1 www  daemon   821776 Sep 13 02:40 vendor.ie.min.js
-rw-r--r--  1 www  daemon   486094 Sep 13 02:40 vendor.ie.min.js.map
-rw-r--r--  1 www  daemon  2498358 Sep 13 02:40 vendor.js
-rw-r--r--  1 www  daemon   727147 Sep 13 02:40 vendor.min.js
-rw-r--r--  1 www  daemon   426508 Sep 13 02:40 vendor.min.js.map

[Hakuyume]

@shtrom How did you apply the patch?

[shtrom]

I didn't. Just upgraded to 1.5.4, I guess from the app store.

I now realise that the patch is probably not merged yet... 🤦‍

[shtrom]

Ok, I patched the app.min.js manually, and it now all works 👍

[ferrolive]

@Hakuyume How can I get this version of jstz that you patched? I'm using the jstz version from Bitbucket.

[Hakuyume]

@ferrolive My patch is not for jstz. It's for nextcloud's calendar app. My patch is available here.

[cmroanirgo]

It's a problem for me too.
Calendar v1.5.6, FF 56, Ext/GMT-10 when it should be +10.
https://pellepim.bitbucket.io/jstz/ returns Ext/GMT-10
A server-side fallback would be a better option than UTC, IMHO. When I noticed the problem, I hunted around for a setting in the UI, in vain :(

[Hakuyume]

I found the bug of Intl was fixed in Firefox 57.
https://pellepim.bitbucket.io/jstz/ reports "Asia/Tokyo" (UTC+9) now. (previously it reported "Etc/GMT-9")

[georgehrke]

Related: #1765

[georgehrke]

I'm closing this issue, because it was mostly a bug in Firefox, which was fixed as per @Hakuyume's comment.

If the calendar detect a user's timezone to be UTC, it will display a warning and ask the user to set the timezone themselves in the calendar-settings.

Furthermore, admins set the default value for a user's timezone. Default is automatic detection, use ./occ config:app:set calendar timezone --value "Europe/Berlin" to set it to something else. (Value has to be an Olsen Timezone)

using ./occ config:app:set calendar timezone --value automatic" resets the default behavior to automatic detection.