Our pure JavaScript Scheduler component


Post by jbrazier »

I've noticed what looks like strange behaviour with the Scheduler Pro when we use the double click event to add a new event.

scheduleDblClick({ date }) {
  console.log(date);
  // Hide Bryntum built-in contextmenu (schedule double click)
  return false;
},

The date parameter that is returned will usually be in GMT at various viewPreset modes e.g. dayAndWeek but when we change the viewPreset mode to monthAndYear the date is returning the date offset by 1 hour (GMT + 1 , BST).

e.g.
dayAndWeek
date = "2023-01-27T00:00:00.000Z"
Wed Jan 25 2023 00:00:00 GMT+0000 (Greenwich Mean Time)
25/01/2023, 00:00:00 with toLocaleString()

monthAndYear
date = "2023-01-27T23:00:00.000Z"
Wed Oct 12 2022 00:00:00 GMT+0100 (British Summer Time)
25/01/2023, 00:00:00 with toLocaleString()

Note: I'm in the UK so the local time is GMT at the moment, so I don't know where it's getting the BST value from

I have tried to reproduce this with a standalone app but it doesn't seem to do this in that app, it always returns the date correctly in GMT.

Is there a setting I can use to ensure that dates are always set to the correct timezone for each view preset?

Thanks,

Jason


Post by jbrazier »

I've managed to reproduce the issue and have attached a video recording of it happening and the simple app I was using.

If I double click at the starting zoom mode of dayAndWeek the event date is GMT.

If I then zoom out to the max level and then zoom back down to slightly less than max e.g. year-50by100 then the event is GMT+1

Thanks,

Jason

Attachments
zoomissue.zip
(126.96 KiB) Downloaded 16 times
Zoom Issue.mp4
(28.28 MiB) Downloaded 14 times

Post by marcio »

Hey jbrazier,

Thanks for the report with the example and video about how to reproduce it.

I created a ticket to investigate/fix it https://github.com/bryntum/support/issues/6080

Best regards,
Márcio


Post by joakim.l »

Hi jbrazier.

If you look at your first example, the first start date is

Wed Jan 25 2023 00:00:00 GMT+0000 (Greenwich Mean Time)

The second start date is

Wed Oct 12 2022 00:00:00 GMT+0100 (British Summer Time)

This is how time zones work in JavaScript, Your local time zone switches to the time zone "British Summer Time" during the "summer".

So, the reason it differs in SchedulerPro's different zoom levels, is because that the start date is different. Zoomed in, the start date has no DST (january) and zoomed out the start date has DST (october). So the timezone is correct, and is nothing the SchedulerPro has anything to do with. It is the client's local operatingsystem that controls what time zone JavaScript dates are "in".

Closing the ticket. But feel free to ask if you got more questions!

Regards
Joakim


Post by jbrazier »

Oh yeah that makes sense, thanks for the clarification Joakim.

Jason


Post Reply