Recurring times wrong with Daylight savings

US follows "Daylight Savings" times, which mean that the clock time changes by 1 hour twice a year.
Unfortunately, it appears that recurring events are probably saved as offsets of UTC (Universal Coordinated Time) [The UTC ordering in the name is because it's using the French word order]

This means that a recurring event which was started before daylight savings time (DST) but repeats AFTER DST is in effect has the wrong start and end times.

For 2015, DST started Sunday 8 March (1 hour forward), and ends 1 November (1 hour backward).
A class that repeats for 6 weeks, starting at 6:00pm comes out showing as if it starts at 7:00pm after March 8th, assuming it was created before the 8th of March.

I have one event that was scheduled at the beginning of the year, every week until the end of the year.

Since it's not possible to set filters by date (which I've suggested in the past), is there any easy way to fix these times? Perhaps an SQL script?

Looking at the database, the times display as local time. I've used some SQL to fix some of them, but I didn't know how to select only child events whose parents were created in a different savings time.
To subtract an hour from an event time, this code works:

There may need to be a PER-EVENT config option to compensate or not compensate for DST. In the off-chance that someone is using EB for reoccurring events at venues both in a DST-observing region and a non-DST-observing region -- eg. a venue in Maidstone, Saskatchewan, Canada (they do DST) and a venue 25km away in Payton, Saskatchewan, Canada (they do not do DST -- same time year round). I think think it'll be a rare case (eg. could effect national tours that occur over the DST change dates in regions where DST does not happen -- eg. Arizona USA or most of Saskatchewan CANADA -- , or local regional events that happen in neighboring towns that happen to be in different DST regions), but it would certainly create problems for reoccurring events. Without a per-event option, users will have to do a manual time change in the DB to compensate. You unfortunately can't static-assign based on the state/province selected -- as in my example above, some regions (like Saskatchewan) are split between DST-observing and non-DST, and some regions (like Nunavut, Canada, one of the northern 'territory' provinces) span three different DST-observing time zones.

I think it can be simplified, and should be easy to implement.

There are two cases: a) The time should stay the same (i.e. 7:00pm class) regardless of savings time or not and b) the time follows savings time (i.e. a global teleconference event)

In the first case, the "7:00 pm" time should always be applied.

The second case could be implemented in a number of ways, but I don't think it needs a per event option, but just a single option. When using this second case, a second time field (hidden) could save the adjusted UTC (Universal) time, and then the display code (Calendars, Event detail, etc) would always convert to the local browser's time. That should automatically handle the savings time issue as well.

Stephan Hodges wrote: Looking at the database, the times display as local time. I've used some SQL to fix some of them, but I didn't know how to select only child events whose parents were created in a different savings time.
To subtract an hour from an event time, this code works:

Code:

`event_date` = DATE_ADD(`event_date`, INTERVAL -1 HOUR),

I think you can use the SQL command:

Note :

#__eb_events need to be replaced with actual table

FROM_DATE needs to be replaced with the start date when time start changing
TO_DATE needs to be replaced with the end date when time stops changing


BTW, these events are created based on what version of Events Booking ? If it is from version 1.6.9+ and PHP version on your server greater than 5.3.x, then this should be handled properly(without having to fix)

Tuan

Thanks very much! I had some of the SQL but that should do it.
Also, of note, I always write a "SELECT" with the where clause first to see the rows that would be affected.
I currently have EB 1.6.10 (current version), and did create the events with it, so not sure what happened.

If you had an online demo/test site, I could try and duplicate it for you.

Again, thanks!