Timezone issues after change of winter to summer time in Europe

[mariobehling]

The time is not displayed correctly. When a user creates an event in Berlin Germany, the event uses the winter time. Adding the event to Google calendar will result in the event being in another time than displayed on the website.

Also changing the timezone to GMT+1 suddenly displays GMT-1 on the public event page.

Expected: The timezone of the event should always correspond to the timezone of the event day. If an event is created during when the winter timezone is active but the event itself is on a date when the time is summer timezone the event time should use summer time.

[none03003]

I want to work in this as i'm new i want gain some experience

[Leslie-Wong-H]

/assign @Leslie-Wong-H

[Leslie-Wong-H]

Root code: https://github1s.com/fossasia/open-event-frontend/blob/development/app/helpers/general-date.js#L33-L34

[Leslie-Wong-H]

Similar issue related: moment/moment-timezone#723

[Leslie-Wong-H]

As for the winter time problem. It seems it is caused by the way how Google Calendar (& Outlook as well) treat the UTC time string information together with location/timezone.

Take this as an example, https://eventyay.com/e/02440ae2

The time string got from backend is {starts-at:"2023-05-26T16:00:00+00:00", ends-at : "2023-05-27T18:00:00+00:00","timezone : "Europe/Berlin"" }

2023-05-26T16:00:00+00:00 and 2023-05-27T18:00:00+00:00 are rendered as Friday, 26 May, 2023 5:00 PM and Saturday, 27 May, 2023 7:00 PM by eventyay with this method.

  let dateTime = moment(params[0]).tz(timezone).format(format);

https://github1s.com/fossasia/open-event-frontend/blob/development/app/helpers/general-date.js#L31-L32

But when it comes to Google Calendar, the URL to create event is like this, https://calendar.google.com/calendar/u/0/r/eventedit?dates=20230526T160000Z/20230527T180000Z&text=Timezone+Test&location=https://eventyay.com/e/02440ae2&ctz=Europe/Berlin. Notice the dates parameter and ctz parameter.

Unexpectedly, it shifts the time one hour later, probably because of their design mechanism of Daylights Savings Time.

Need more elaboration about the underlying behaviors that moment.js handles DST.

[Leslie-Wong-H]

Valuable documentation about Google Calendar URL

Calendar URL generator which parameters -Google Calendar Help

add-event-to-calendar-docs/services/google.md

The source code that eventyay uses to visit Google Calendar:

open-event-frontend/app/components/public/add-to-calender.ts

Line 69 in 45eec1c

get googleUrl(): string {

[Leslie-Wong-H]

Tricky enough.

  get startsAt(): Moment {
    const { event } = this.args;
    return moment(event.startsAt).tz(event.timezone);
  }

  get endsAt(): Moment {
    const { event } = this.args;
    return moment(event.endsAt).tz(event.timezone);
  }

  get calendarLocation(): string {
    return this.args.event.online ? this.args.event.url : this.args.location;
  }

  get googleUrl(): string {
    const { event } = this.args;
    const startTime = this.startsAt.utc().format('YYYYMMDD[T]HHmmSS[Z]');
    const endTime = this.endsAt.utc().format('YYYYMMDD[T]HHmmSS[Z]');
    return `https://calendar.google.com/calendar/render?action=TEMPLATE&dates=${startTime}/${endTime}&text=${event.name}&location=${this.calendarLocation}&ctz=${event.timezone}&details=${this.description}`;
  }

https://github.com/fossasia/open-event-frontend/blob/45eec1c3eb1d4983c1d1a74abf09103a32202d15/app/components/public/add-to-calender.ts#L55C7-L74

[Leslie-Wong-H]

A StackOverflow answer to Does UTC observe daylight saving time?:

No, UTC itself never has DST. It is the constant frame of reference other time zones are expressed relative to.

From the Wikipedia UTC page:

UTC does not change with a change of seasons, but local time or civil time may change if a time zone jurisdiction observes daylight saving time or summer time. For example, UTC is 5 hours ahead of local time on the east coast of the United States during winter, but 4 hours ahead during summer.

In other words, when a time zone observes DST, its offset from UTC changes when there's a DST transition, but that's that time zone observing DST, not UTC.

Without knowing much about PHP time zone handling, it seems strange to me that you can specify "with DST" or "without DST" in a conversion - the time zones themselves specify when DST kicks in... it shouldn't have to be something you specify yourself.

https://stackoverflow.com/a/5495816/8808175

Since eventyay seemingly uses server-side UTC-0 time to mark timestamps with timezone, I doubt the feasibility to fix this bug.

[Leslie-Wong-H]

Pardon, it should have a workaround.

[none03003]

If It's giving timestamp error maybe cause of node is not updated?

[Leslie-Wong-H]

If It's giving timestamp error maybe cause of node is not updated?

Why 'node'? It's the browser environment.

[none03003]

I thought hence we are using Google timestamp so there are updated all systems and ours is not so maybe some errors is occurring? And we also got new issue to update node cause some test and function giving errors

[cweitat]

@Leslie-Wong-H will you be working on this?

[ayushgupta9906]

I want to work on this. Please assign it to me

[github-actions]

We don't assign issues to external contributors. Please comment that you're working on the issue after checking that no one else is, and then send a pull request for it. Thank You!

[ayushgupta9906]

I am working on this issue.

[Leslie-Wong-H]

As for the winter time problem. It seems it is caused by the way how Google Calendar (& Outlook as well) treat the UTC time string information together with location/timezone.

Take this as an example, https://eventyay.com/e/02440ae2

The time string got from backend is {starts-at:"2023-05-26T16:00:00+00:00", ends-at : "2023-05-27T18:00:00+00:00","timezone : "Europe/Berlin"" }

2023-05-26T16:00:00+00:00 and 2023-05-27T18:00:00+00:00 are rendered as Friday, 26 May, 2023 5:00 PM and Saturday, 27 May, 2023 7:00 PM by eventyay with this method.

  let dateTime = moment(params[0]).tz(timezone).format(format);

https://github1s.com/fossasia/open-event-frontend/blob/development/app/helpers/general-date.js#L31-L32

But when it comes to Google Calendar, the URL to create event is like this, https://calendar.google.com/calendar/u/0/r/eventedit?dates=20230526T160000Z/20230527T180000Z&text=Timezone+Test&location=https://eventyay.com/e/02440ae2&ctz=Europe/Berlin. Notice the dates parameter and ctz parameter.

Unexpectedly, it shifts the time one hour later, probably because of their design mechanism of Daylights Savings Time.

Need more elaboration about the underlying behaviors that moment.js handles DST.

The mis-logic of this issue is this way. Referring to https://clocks.world/time/germany/berlin/, since March 26 2023, the CET time that Berlin adopts is 2 hours ahead of UTC0, and the status quo here is that
Design time: when reading the three input box information to generate a time string, the generated time string still follows the 1 hours ahead logic, not 2 hours ahead, from "2023-05-26T17:00:00+01:00" getting "2023-05-26T16:00:00+00:00" when converting back to utc0 string, ironically the wrong string gets rendered correctly at the system run time. Yet when sending information to Google Calendar, they treat "20230526T160000Z" with 2 hours ahead logic concerning CET/Berlin, therefore comes an unexpected mismatch. The other Calendars iCal, Yahoo, Outlook may also render wrong results accordingly.

Inspiration: Find the core code that eventyay uses to generate event time string to post to server and use the DST-safe Temporal Polyfill to ensure the utc0 correctness. Or figure out why moment-timezone is not handling utc0 correctly.