I’ve added links for the site-level calendar and agenda to the hamburger menu. The can be enabled (and disabled) using the events_hamburger_menu_calendar_link and events_hamburger_menu_agenda_link site settings.
There is already a site-level setting for “No text on add event buttons”.
For each site level setting mentioned above the category level setting will override the site level setting. For boolean settings, a false category-level setting will also override the site-level setting. This means that if you have already set a category-level setting for a category, the site level setting will not apply to the category.
My general thinking is that the timezone should be included in emails as there is no way to detect a user’s timezone in the email client.
Even for communities that are specific to an area like yours there still may be circumstances in which a timezone becomes useful, like when you went to Paris .
But perhaps I should still add a setting to not include timezones in emails. I can see the argument in your case. I’ll add that this weekend.
Also, you should use the new default timezone site setting (i.e. set it to London rather than UTC).
hm right, yeah, it’s because I’m now using “Friendlier” labels generated by Rails in the UI and the official zones underneath the hood. Sometimes two labels refer to the same zone.
The select-kit gets confused when two labels refer to the same value. I’ll figure out some fix to that at some point, but as you say it’s not a big issue.
Probably a daylight saving time issue. I could have sworn I set the timezone to London. Should this be sufficient for the plugin to account for daylight saving time adjustment?
Also the date appears to show as a range although only a single date was entered.
@angus kindly helped me test the issue with dates in emails being one hour out. It looks like the timezone setting on my forum must have been UTC at the time of the issue (rather than London) which meant that this was a daylight savings time issue.
I could have sworn I set the timezone correctly when I first installed the plugin but in any case, I don’t think there is any issue with the plugin itself here.
Is it possible that the user‘s computer/phone has a wrong timezone? The locale is only used for date/time formatting using moment.js afaik. The time for your event shown to me is also 20:30. My timezone is Berlin.
As @craisp suggested, the way it’s meant to work is that it shows the user the event time in their own timezone. If the user is in Germany the time will be different.
I added the setting Include timezone in event label. to handle the case of users in multiple timezones, i.e. so there would be no confusion about what time was being displayed.
However I guess you’re after a setting that will always show the event in a certain timezone.
Well now that we have a default timezone, this is possible without also requiring the timezone to be entered each time an event is added. So I’ll add it.
Updated tasklist (for my reference);
1 - Address long title display.
2 - Add setting to always display time in default timezone, unless timezone is explicitly set.
3 - RSVP feature(@steve_pd I haven’t forgotten about this, sorry it’s taking so long).
Now when you click on an event in the calendar in desktop, you will see an event card, with the topic title, metadata (including event label) and a topic excerpt. Clicking the title, the event label or the excerpt takes you to the topic itself. Event cards do not display on mobile. They are somewhat similar to the event details display in Google Calendar.
@tobiaseigen This addresses the title display issue.
For creating, editing and displaying an event, the timezone is set according to this hierarchy:
// Start with the user's timezone, guessed by momentjs.
let timezone = moment.tz.guess();
// If a default timezone is set in the site setting use that instead.
const defaultTimezone = Discourse.SiteSettings.events_default_timezone;
if (defaultTimezone) {
timezone = defaultTimezone;
}
// If the event has a custom timezone use that instead.
if (event['timezone']) {
timezone = event['timezone'];
}
return timezone;
The decision on whether or not to display a timezone label next to a datetime is determined according to this logic:
Basically, if the event is not an all day event and has a custom timezone that is different from the standard timezone (either the site setting or the user’s own timezone), then the timezone is displayed.
Zone list
I’ve also updated the timezone list (used for both the default timezone setting and the custom timezone input in event creation / editing modal) to filter duplicate values in the ActiveSupport::TimeZone::MAPPING. This simplifies the selection of zones (e.g. prevents issues with having objects with duplicate keys in a combo-box)
timezones = ActiveSupport::TimeZone::MAPPING
zone_map = []
remove_zones = []
# Remove the duplicate zones where the label doesn't include the city in the zone.
timezones.each do |k, v|
if zone_map.include?(v)
duplicates = timezones.select { |key, val| val === v }
remove = duplicates.select{ |key, val| !val.include?(key) }
remove_zones.push(*remove.keys)
end
zone_map.push(v)
end
timezones.except!(*remove_zones)
Basically, this means that when you have two or more “Readable” labels referring to the same IANA zone such as
The zone with a label that does not match in the city in the IANA zone is removed. In this case Edinburgh would be removed.
Emails
The timezone of event times in emails is set according to this logic:
event_timezone = SiteSetting.events_default_timezone
event_timezone = event[:timezone] if event[:timezone].present?
i.e. Start with the default timezone, then use the custom event timezone if one is used.
I’ve also added a setting that toggles the display of timezones in event emails: events_emails_include_timezones. Default is true. The event time in the email is still going to be localised according to the logic above regardless of this setting.
@ChrisBeach Amongst other things, I hope this addresses your various timezone issues.
.
