SchedulerPro Timezone Setting Inconsistency

[xnasav]

Hello Bryntum-Team,

We may have found a little inconsistency in the logic of the scheduler pro when manually configured with a timezone (or we just don't understand something). In attached pdf you will find code that you can post in one of your demos (we used this one: https://bryntum.com/products/schedulerpro/examples/timezone/).
As you can see in the code we configured the schedule to use Etc/UTC timezone. When we try to calculate the working time between two dates (particularly

'Mon Dec 11 2023 00:00:00 GMT+0100 (Central European Standard Time)'

and

'Sat Dec 16 2023 00:00:00 GMT+0100 (Central European Standard Time)'

. The result is 428400000ms which results in 4.95 days when converted. We expect this to be 5 days and can't explain the odd number. We also tried with

01:00:00 GMT+0100

for both dates (which would be 00:00:00 in UTC date) and the

ignoreTimezone: true

flag for the calendar config but the result is the same.

Only this

calendar.calculateDurationMs(
      new Date('Sun Dec 10 2023 23:00:00 GMT+0100 (Central European Standard Time)'),
      new Date('Fr Dec 15 2023 23:00:00 GMT+0100 (Central European Standard Time)'),
 ),

results in a timespan of 5 days.

Thanks in advance for any information about that.
Best regards

[joakim.l]

Hi!

That's a bug. Here's the ticket to track our progress https://github.com/bryntum/support/issues/8861

Thank you for reporting this to us!

[xnasav]

Hello Joakim,

Thanks for the confirmation. Unfortunately we think we stumbled across something else in regards to timezones.
We have a schedule configured with a timezone (in attached code example UTC using this demo https://bryntum.com/products/schedulerpro/examples/timezone/) and define a listener (e.g. a schedule click). The date that is yielded within the context of the event is still in local timezone. E.g. When i click in the grid cell of 08:00 AM it yields the time of 08:00 +01:00, instead of 08:00Z or 09:00 +01:00, which is what we would expect.

Any help would be highly appreciated.

[joakim.l]

Hi!

The currently implemented time zone support is a bit limited. When configuring the Scheduler with a timeZone, all dates will be converted so as they appear to be that time zone. But technically, since JS Date doesn't support time zones, they are still in the local system time zone.

We've made so the dates will be converted back when reading fields for persistability, like saving data.

But if you read the values, like in the listener in your example, you get the correct time if you ignore the time zone info on the string representation. A date value of 2024-03-25T14:00Z in a Scheduler configured with the timeZone UTC, will on any local system time zone display a date value like 2024-03-25T14:00 + the local system time zone offset.

So, if you need to do anything with the dates on client side, you should use the TimeZoneHelper to convert them back to real local system time.

I know this can be a bit confusing, and not ideal at all. But this is our temporary implementation of time zone support until JS gets real support for it.

[xnasav]

Hey Joakim,
Thanks for the answer. I understand that there is no native support for timezones in js currently, which is why we were very happy that Bryntum seemed to have offered a suitable workaround for that. I also understand that 2024-03-25T14:00Z would be displayed the same on every clients machine (independent of the local timezone) if the scheduler was configured with UTC timezone. And that's exactly why we are so surprised that the provided date in the schedule listeners is incorrect. We now have to manually "ditch" the timezone information of every scheduler event date to get the correct UTC date.
A disclaimer in the config for the timezone property would have really helped.

[joakim.l]

Thank you for your feedback! We are happy to recieve input to be able to improve both our documentation and our features.

The timeZone config contains some information, what would you suggest we should add? We also have a guide.

What is your use case where you need to "ditch the timezone information"? Maybe we can suggest some other approach, or if possible, add some functionality to make the current time zone support easier to use.

[xnasav]

Our use case is to display the same looking schedule to every client (independent of the timezone) as we rather have a plan than an calendar/schedule of timestamped events (where the actual time information would matter). Therefor our approach was to convert our persisted event's dates to UTC (e.g. 25.03.24 00:00Z to 30.03.24 00:00Z) and configure the schedule to use UTC timezone.
These events are displayed as expected, but whenever you interact with the schedule (e.g. click into the schedule like stated above, or move an event via drag and drop) you get back a listener event with a date where the local timezone information is attached.
This means that, assumed that you want to move previously mentioned event one day into the future, the date you receive from the listeners needs to be converted to a UTC date (and hence loose ("ditch") it's timezone information) before we can save it to our data storage.
Edit: To make our expectation clearer. We expected the same timezone format we pass into bryntum (and with which the instance was configured to) to also be emitted in the listeners.
Additionally we figured that "no dst support" means that, even when a timezone without dst change (e.g. UTC) is selected, there is still the dst change happening anyway, is that correct? We just tried to move an event from today to the 31.03.24 (which in Berlin timezone is the day of dst change) and it got an hour longer visually.

[joakim.l]

You're completely right. The DST transitions of the local system time zone will result in incorrect dates displayed. As your example, in CET, 2024-03-31T02:00 don't "exist".

When event dates changes, how do you save? If you're using our Stores in-built sync, the dates will be converted before sent to the backend. Otherwise, maybe you could use modificationDataToWrite.