Display reminder of user timezone above calendar

[samuk]

Users don't always correctly set or update their timezones.

Could we add some text above the calendar;

Your current timezone is <UTC +1> adjust timezone

[samuk]

@funkycram Is this one you could look at?

[marc-farre]

@luke- PR #396

@samuk it's not exactly your request. I think we need to show the time zone beside the time, as suggested in this PR:

Because events can be viewed also in stream, and on the calendar the time don't displays on the Month view.

I didn't add the link to update the time zone because I think it will overload the view and it's not a common practice on Humhub to show links to the settings. E.g. on the notifications list, we don't show a link to change the settings.

Perhaps with the "Tour" module we could help the user updating the time zone and other settings, because this module shows for new accounts. Later, we don't need to always see links to update the time zone or other settings.

[luke-]

Thanks for the PR.

Hmm, I unsure that we should display the time zone that prominent.
Instead, it would be better to make sure that the user has set a correct time zone.

Some ideas:

• We could introduce a new option time_zone_auto which automatically sets the user's time zone to that of the current browser after each login?
• Only show the time zone of a event when it differs from the user's time zone
• As in this original issue request, show the current user time zone in calendar view (somewhere small as reminder)
• Maybe we could adjust your solution, more decent in light grey..?

[marc-farre]

Thanks @luke- for these ideas!

1. This is a very good idea (requires ajax), but it might add confusion when logging in with another device (e.g. your phone has a different timezone than your computer, mainly in countries like the USA having many time zones).

But I think it would be a good idea for new account creation. We could show the time zone field on the registration form and JS would automatically, if available from the browser, select the browser's timezone.

2. The problem we have is that 99% of the user have the Humhub global time zone (the on setup in the administration). So the users and event time zones are nearly always the same.

3. I though it wasn't the best idea, because events can be viewed also in stream, and on the calendar the time don't displays on the Month view.

4. Yes, what would you think about a small label such as this one?
   
   Commit: 67195b1

[samuk]

"Later, we don't need to always see links to update the time zone or other settings."

The problem is users are not static. They have a tendency to move.

The browser detection on signup sounds like a nice idea and worth doing, it still doesn't solve the problem as users move timezones though.

Can we do the 'show the current user time zone in calendar view' option alongside browser detection?

Thanks

Sam

[marc-farre]

If you both think it's better to display the time zone on the calendar view, I'll like to have a suggestion where to display it.
And as you can see on the screenshot, there is no mention of time on this view, so that's why I though it was better to display the time zone next to the time.

[luke-]

@Eladnarlea Can you please take a look here?

[dantefromhell]

We could introduce a new option time_zone_auto which automatically sets the user's time zone to that of the current browser after each login?

Forcing a timezone this way does not work well on Browsers that have tracking prevention enabled like Brave.
Equally when I am travelling and want to adjust certain apps to the local timezone, but not my whole system this would get in the way.

My suspicion is that most platforms open a dialog to ask users for confirmation changes due to a variety of corner-cases where real life collides with this detection mechanism.

[marc-farre]

@Eladnarlea what do you think about it? Thanks!

[Eladnarlea]

@marc-farre I will discuss this matter with @luke-. I like some suggestions but it is more complex and implementation requires more time as it might seem as it comes along with other timezone problems. At the moment we focus on wrapping up other projects but your issue is definitely on our list of things to improve.

[samuk]

Thanks @Eladnarlea.

@marc-farre is it possible to do some short term fix on our local instances while we wait for this to be resolved upstream? It's an ongoing issue for us. People miss meetings with some regularity.

[dantefromhell]

I've been pondering about a good solution recently and I must say I really like @marc-farre approach of adding the timezone (maybe the abbreviation instead of full location)[1] right after the time info.

For those that are aware of different timezones (not all users are in my experience) it makes it a full statement.
Having the timezone listed somewhere else makes it more cumbersome to find all relevant information.

When it comes to adjusting times I would vote for the server always emitting timestamps that include a timezone information (possibly the server timezone) in an HTML <date> element instead of a string.

Javascript can now take care of adjusting the <date> element according to what the browser reports as current timezone without the server needing to know this info.
I found the following article helpful to understand the concept
https://dev.to/kovah/easy-date-and-time-localization-with-the-time-html-element-3a69#:~:text=You%20can%20use%20the%20HTML,Let's%20start%20with%20the%20basics.

I also vote for displaying time in the timezone reported by the devices used for viewing a page. Given this is mostly an issue for people travelling and/ or living in countries with multiple timezones and my personal experience with both scenarios portable devices (phones, laptops) have become pretty good at automatically picking up my timezone changes.

In my experience relying on the OS+Browser reported timezone will create the less issues than requiring users to change their timezone setting within a HumHub instance.

Update [1]
I played around with some PHP code using

Yii::$app->formatter->asDateTime(time(), "php:T")

but it turns out the mapping between different locations to timezone abbreviations only works partially, resulting in more UTC+<OFFSET> outputs than I liked.