All-Day Events with UTC Data Behave Inconsistently and Change on Save with Local Timezone

[Dhruvi Mirav Prajapati]

Environment:

• Syncfusion Angular Version: (e.g., @syncfusion/[email protected])

• Angular Version: 14.0.5

• Browser: Chrome

---

Hello Syncfusion Team,

I am encountering some confusing behavior with all-day events when using UTC data and setting a specific timezone on the scheduler. There are two main problems: incorrect initial rendering and data changing upon saving an event.

I have created a StackBlitz that clearly demonstrates these issues:(you will need to set your system timezone to ist )

https://stackblitz.com/edit/angular-xorepdxc-vbdfud6h?file=src%2Fmain.ts

---

## Detailed Problem Description

My scheduler is configured with [timezone]="'America/Los_Angeles'" (PDT). My event data is provided in UTC.

Problem 1: Incorrect Initial Rendering

As you can see in the StackBlitz, the rendering of all-day events is inconsistent:

• "15 Diff day 12 am" (StartTime: '...15T00:00:00Z'): This event is meant for August 15th but it renders across August 15th and 16th. 

• "12 Diff day 7 am" (StartTime: '...12T07:00:00Z'): This event is meant for August 12th but it renders across August 12th and 13th. This is 12 am pdt in utc. 

• "8 same day" / "10 same day"/"24 same day": These events have the same StartTime and EndTime, which doesn't follow the exclusive end date rule and renders as a zero-duration event but correctly visible in ui as all day.

• "25 diff day":   (StartTime: '...25T18:30:00Z')  (EndTime: '...26T18:30:00Z') : this event is visible correctly and even when saved without changing the event, the start and end date string doesnt change​
  

Problem 2: Data Changes on Edit/Save

This is the more critical issue. If you perform the following steps:

1. Open any existing all-day event (for example, the correctly formatted "12 Diff day 7 am").

2. Click the "Save" button without making any changes.

3. Check the console log from the actionComplete event.

You will see that the original UTC Date object is replaced by a Date object in my browser's local timezone (GMT+0530, India Standard Time).

• Before Save: StartTime: Tue Aug 12 2025 00:00:00 GMT-0700 (Pacific Daylight Time) (Correctly interpreted UTC)

• After Save: StartTime: Tue Aug 12 2025 00:00:00 GMT+0530 (India Standard Time) (Incorrect local time)

This happens because the editor popup creates new Date objects using the browser's local timezone, effectively corrupting the UTC data source.

---

## My Questions

1. For all-day events, is it the intended design that we must always provide UTC timestamps that are pre-adjusted for the target timezone (e.g., T07:00:00Z for PDT)? Is there a simpler way to just use a date like '2025-08-12' and have it respect the IsAllDay flag?

2. Is there a built-in way to prevent the editor from converting UTC dates to the browser's local timezone upon saving? Or is the recommended solution to manually intercept the actionBegin event and convert the dates back to UTC, as I've seen suggested?

Thank you for clarifying the expected behavior and best practices for this scenario.

[Vijay Ravi]

Hi Dhruvi Mirav Prajapati,
 

1. Problem 1: Incorrect Initial Rendering
 

The Cause: The primary reason for the incorrect rendering was your mapToScheduleEvents function. This function was returning event objects with undefined for the StartTime and EndTime properties, causing the scheduler to behave erratically.

Furthermore, the inconsistency in your data leads to the rendering confusion. When you set timezone="America/Los_Angeles", the scheduler converts all UTC date strings to that timezone for display.

For an all-day event on a specific date (e.g., Aug 10) to render correctly in a target timezone, its UTC StartTime must correspond to midnight (00:00) on that date in that target timezone.

Example: America/Los_Angeles is PDT (UTC-7). To create an all-day event for August 10th, the UTC time must be 2025-08-10T07:00:00Z. Your event for Aug 10 was at T00:00:00Z, which is 5 PM on Aug 9th in Los Angeles, so the scheduler correctly rendered it starting on Aug 9th.

The Fix: I have removed the call to mapToScheduleEvents and now pass your eventDataSource directly to the scheduler. This resolves the immediate errors. For perfect rendering, you should normalize your source data so that all-day events have a UTC time that reflects midnight in your target timezone.

2. Problem 2: Data Corrupted on Save
 

The Cause: When you edit an event, the scheduler's editor works with Date objects. These JavaScript Date objects are based on the browser's local timezone (IST in your case). When you save, the scheduler returns these local Date objects. Your original onActionComplete did not handle this, so your UTC data source was being updated with local time objects, effectively "corrupting" the timezone consistency.

The Fix: The new onActionComplete function solves this robustly:

It intercepts the data from eventCreated and eventChanged actions.

It takes the StartTime and EndTime Date objects returned by the scheduler.

It immediately converts them back to UTC format using the standard .toISOString() method.

It updates your master eventDataSource with this clean, timezone-consistent UTC data.

Finally, it refreshes the scheduler's eventSettings to ensure the UI reflects the updated and correctly formatted data.

Don't hesitate to get in touch if you require further help or more information.
 

Regards,

Vijay