Timezone + dHTMLxScheduler

Hello,

I’ve got 2 questions:

1-Is it possible to set default time when in month view I create a new event?

actually scheduler adds an event at 00:00, is it possible to configure it to add an event at 08:00??



2-is there any configuration to avoid a problem with solar time?

if I try to add an event in month view on 27/10/2009 scheduler adds an event on 26/10/2009



thanks in advance



Giorgio

1-Is it possible to set default time when in month view I create a new event?

scheduler.attachEvent(“onEventCreated”,function(id,e){ //occurs exactly after event created, but before details showing or saving
var ev = scheduler.getEvent(id);
if (scheduler._mode == “month”){ //if month mode
ev.start_date.setHours(7); //set new initial time
ev.end_date.setHours(7);
}
})

>>2-is there any configuration to avoid a problem with solar time?
Problem confirmed. The scheduler handles shifting from winter time to summer time correctly, but fails for backward shift days.
Fix will be available in few days.

ok, thanks
I’ll wait for the bug fix…

Fixed version of scheduler is attached to the email.
codebase_tf.zip (47.9 KB)

Hello,

 I’ve tried  the bug fix but it seems to be still not properly working, now that we have winter time all the events are added the day before at 23:00

Giorgio

sorry, the problem still occours not every but when I try to add a new event in summer time (now that we are in winter time, events added in winter time are correctly added)
hope this helps to find and solve this bug


  Giorgio

I am tracking the issue here, too: Summer/Winter time creates offset · Issue #154 · niccokunzmann/open-web-calendar · GitHub

Hello @niccokunzmann ,

It’s a known issue and the team considers ways to fix it, unfortunately there is no any ETA when it will be fixed.

Kind regards,

The way I think, it is solved at the moment is that the DHTMLX-scheduler sends the time zone offset but I additionally send the user time zone. The user time zone is the one that is used to generate the event times. Also, I remember that the option that the server sends UTC events is disabled. This way, the event times are taken as the server sends them and the time zone is actually the one send to the server, chosen by the browser.

Did this ever get fixed? I’m having this problem now

It is probably not built in, yet but easy to add. Timeshift cannot remove the offset - impossible.

JavaScript: timezone= parameter
getTimezone()
add to scheduler URL

Timeshift can be added. Being able to handle other timezones requires a bit more on the server side.

1 Like

@niccokunzmann thank you for the prompt response.

I’m in the UK and we just moved forward 1 hour for daylight saving (DST).

What am I looking at here? I don’t have these files in my project?

The date submitted to my backend REST server shows the correct date, it would appear to be correct in my SQL query, but when I check the database it has reduced by 1 hour.

I don’t believe the dhtmlx Scheduler has been out all this time and that this is problem that hasn’t been addressed, there must be something I’m missing?

I’ve tried:
scheduler.config.server_utc = false

At SQL query shows: '2024-04-10 00:00', but database shows 2024-04-09 23:00

and

scheduler.config.server_utc = true

At SQL query shows: '2024-04-09 23:00', but database shows 2024-04-09 22:00

Thank you.

Hi, I cannot really help with this much!

scheduler.config.server_utc = false - yes, that expects local time - you should return events in the local time zone of the person viewing the calendar - You would do the calculation on your server and return the events in that time zone. Somehow, you need to pass the timezone and you can have a look at how I did it in the PR or in the code linked. I chose this solution with the timezone calculation on the server. I ignore the offset except if I cannot find the timezone parameter.

JavaScript/Client side:

Python/Server side:


I do not know much about the specifics of the timezone implementation of the scheduler. An easy implementation for the team might be (already implemented?) that requests for events that span over different timezones are split up into two: One before and one after the timezone change with different offsets. Events then need identification though so there is no duplicate … That makes it harder again.