Premium support for our pure JavaScript UI components


Post by jq123 »

We are trying to use the timeZone prop on Bryntum Calendar, and we had some questions about the behavior. If the behavior below is the confirmed to work as expected, the behavior doesn't seem very intuitive.

Preconditions

  • I am a User with a local time of California PDT, and our application uses Japan Time in an external configuration

  • I set the timeZone prop to "Japan Standard Time"

  • See Google Calendar for an example of (local time and "Time Zone" )

  • I am attempting to use the new timeZone prop on Bryntum ProjectModel in v5.3.5

Test Case 1 : Current TIme Redline Marker

  • If it is Tuesday May 23 2023, 4PM on my local computer (PDT)

  • When I open the Calendar, then the "current time redline marker" should be Wednesday May 24 2023 8AM JST

  • We expect the redline to be at 8AM, but the redline is incorrectly set to 4PM PST

Test Case 2: General timeZone prop expectations with onScheduleClick

  • When I click a timeslot corresponding to 8AM on the calendar

  • Then it should know that I am referring to 8AM JST, and the onScheduleClick callback should return me a Date corresponding to May 23 4PM PDT, which is equivalent to May 24 8AM JST or May 23 23:00 UTC

  • Current behavior fails because it incorrectly returns May 24 8AM PDT instead of May 24 8AM JST

image (5).png
image (5).png (58.11 KiB) Viewed 225 times

Post by joakim.l »

Hi!

Thank you for reporting this to us. The time zone support is quite new and is both bound to have a few bugs.

The Calendar current time line is indeed incorrect, it should be converted to the specified time zone, but it isn't. I've created a ticket for it, and we'll se to it that it's fixed.
https://github.com/bryntum/support/issues/6839

Your second report, however, is a bit more complicated. The time zone support is a quite simple implementation in that sense that it only converts the dates as they "would be" in the specified time zone. The Calendar (in this case) is not (with some exceptions) aware of any time zone. Only the project and the records which holds the dates are aware of that. JavaScript currently has no support for dates with time zones, so all dates will technically always be in your local system time zone.

So getting the converted date in your onScheduleClick is "by design". You would need to call the TimeZoneHelper to convert them back to your local time zone, if that's what you want. That's done automatically when syncing the store, for example.

This is our current time zone support implementation. We aim to have complete time zone support when the Temporal API is generally available.

Regards
Joakim


Post by jq123 »

Hey joakim.l,

Thanks for filing the bug for the redline marker. We were wondering whether we can pick up the fix for the redline marker without having to set the timeZone prop (maybe as an additional prop?). The issue is that we are already using TimeZoneHelper to shift our dates, and setting the timeZone prop will perform an additional shifting on the Calendar events. As a result, some events will get shifted twice (once by the timeZoneHelper and again by the timeZone prop).

As you've mentioned, onScheduleClick will require us using TimeZoneHelper to fix, but then by using the timeZone prop, we now have 2 different APIs colliding.


Post by joakim.l »

There is no official way of affecting the date which is used by the current time indicator in the Calendar. What's the reason for avoiding using the timeZone config and instead converting the dates manually?

Regards
Joakim


Post by jq123 »

Here's the scenario we're encountering by using both the timeZone prop and TimeZoneHelper:

  1. Local system is in PST, Calendar event is stored in EST, timeZone prop is set to 'America/New_York'.
  2. User schedules an event at 9AM EST
  3. onScheduleCallback fires, and we shift the time to 6AM PST using TimeZoneHelper. This is correct because we need to store 9AM EST, which equals to 6AM PST.
  4. Since the timeZone prop is set, the event is shifted 3 hours to 9AM PST (this additional shifting is incorrect).
  5. The event appears at 12 PM EST on the calendar
    So you can see above, our problem is that combining timeZoneHelper with the timeZone prop causes the events to be shifted too many times.

Post by joakim.l »

Hi!

Could you please provide a code example with instructions how to reproduce this behaviour? That way I can see if anything should be done on our end, or suggest another approach.

Regards
Joakim


Post Reply