Save event start and end as datetime, and also save timezone

[psrpinto]

Currently, event start and end dates are stored as YYYY-mm-dd. This means that it's not possible to have events that last only a portion of the day, for example 18h00 to 21h00. I think it would be useful to support partial-day events, for example WordPress meetups and such.

Additionally, no timezone information is stored. I think the timezone is important because otherwise it's not possible to accurately tell whether a translation is part of an event or not.

[trymebytes]

I agree, this is important for the stats gathering as well, where we need ti determine the contributions of the attendee within the period when the event was active.

[psrpinto]

Been thinking more about this, and concerning timezones, I think datetimes should be stored as UTC, so all calculations can be made on UTC.

In this case, I think we would need to store the timezone of the event, and convert from said timezone to UTC before saving the datetime in the database. Whenever we need to display that datetime to the user, we would then convert from UTC to the event's timezone.

Does this make sense?

[amieiro]

I think we need to store the Datetime for the start and end of the event, but we don't need the timezone, because we could have users in the event in different timezones:

• When a user creates the event, we can get her timezone using JavaScript and calculate the difference before storing in the database.
• Once we have the event, when we show the info to the user, we need to get her timezone and then do the calculation to show her the datetime in her hour and in UTC format.

[psrpinto]

Storing datetimes in UTC, and converting to the user's timezone for viewing makes sense 👍

When a user creates the event, we can get her timezone using JavaScript and calculate the difference before storing in the database.

I think there might be a problem with this, if the user creating/editing the event is in a different timezone than the timezone of the event. For example, if I would create the event for WordCamp Asia, the timezone would be Lisbon instead of Taiwan.

I think this could result in stats being wrong, because we only save the translation in our stats table if it's "inside" an event, and we would be comparing to Lisbon time instead of Taiwan time.

[trymebytes]

I discussed this with @akirk and he suggests we could use <input type="datetime-local">. I think we can then add another field for the time zone just like it's done when you try to create an event in Google Calendar.

[amieiro]

Storing datetimes in UTC, and converting to the user's timezone for viewing makes sense 👍

When a user creates the event, we can get her timezone using JavaScript and calculate the difference before storing in the database.

I think there might be a problem with this, if the user creating/editing the event is in a different timezone than the timezone of the event. For example, if I would create the event for WordCamp Asia, the timezone would be Lisbon instead of Taiwan.

I think this could result in stats being wrong, because we only save the translation in our stats table if it's "inside" an event, and we would be comparing to Lisbon time instead of Taiwan time.

I will explain my suggestion with the WC Asia example (the usual situation will a user creating an event for her timezone, but of course, we should develop it for all situations). Imagine you (Europe/Lisbon: UTC in winter, UTC+1 in summer) want to set the event for WordCamp Asia 2024 (Taipei, UTC+8, without DST). WordCamp Asia’s Contributor Day will be on March 7, 2024. I will suppose it will start at 9:00 am local time.

In the UI for the one who will create the event, we can take 2 different approaches:

• Add 2 datetime pickers to select the local time for the start and end of the event. Add a dropdown with the timezones (you will select Asia/Taipei).
• Add 2 datetime pickers with your local time, but you need to do the conversion, so this is a worse approach.

In both situations, I will suggest storing the 2 datetime pickers in UTC, and the timezone (in string format, Asia/Taipei), so when we will need this information:

• We can calculate the local time for the event using the UTC datetime and the timezone offset.
• We can do the same for users in different timezones. We can use JavaScript to get her timezone and calculate the difference.

And when a user stores a translation, it is very simple to know if the event is active or not, because we are using UTC datetimes for the start and the end of the event.

[psrpinto]

This makes sense to me @amieiro 👍

In the UI for the one who will create the event, we can take 2 different approaches:

1. Add 2 datetime pickers to select the local time for the start and end of the event. Add a dropdown with the timezones (you will select Asia/Taipei).
2. Add 2 datetime pickers with your local time, but you need to do the conversion, so this is a worse approach.

I agree approach 1. is best. I think users, when creating the event, will be thinking "I'm setting the properties of the event", so I think it makes sense that they also set the timezone of the event. Like Google Calendar does it, for example.

Thinking about Google calendar again, when you create an event, it defaults to your own timezone. If you want a different timezone, you select it in a dropdown. I think we could do something similar, so it could default to WordPress's timezone, or the browser's timezone, like Jesús suggests.

The timezone should probably be a mandatory field so it's always stored. It would just be prefilled with the user's timezone.

Later, if we decide to implement adding a location to the event, we can also consider prefilling the timezone dropdown with the timezone of the location.

[amieiro]

Yes, I think using by default the user's timezone instead of the WordPress' timezone is a better approach, because translate.w.org (UTC timezone) has users in most of the timezones, so e.g., a user in Tokyo (UTC+9) will get a very different time than her own time if we use the WordPress' timezone, and this sometimes is weird for the end user.