3

I have an event table that should store events (dt_start, dt_end, all_day,etc).

I saw that .ical files stores dt_start and dt_end as the same day (without time) for an "all_day" event.

Question: if I have an event on 2015.09.08 all day, how it should appear for a user that has a different timezone? Along two days? or a single day?

Improve this question
1
  • 1
    Personal opinion: It should appear as a single day (on September 8, 2015). Usually, an "all day" event/appointment doesn't actually last 24 hours, but rather is used to mark the block of time that you are working/awake during a day.
    – Bart van Ingen Schenau
    Commented Sep 8, 2015 at 11:26

1 Answer 1

Reset to default
2

If someone gave that problem to me, I would probably do the following:

All the data in the system should be stored in one time zone (normally UTC), then only when the value needs to be printed to the output should time zone offset be applied.

The user sets an all day event, which would appear to the user as 00:00:00.000 - 23:59:59.999 in the user's local time. This means that finding scheduling conflicts is trivial, as opposed to having to check somehow if an event is marked as all day.

Now, as for storing it, if you have users in different time zones the best thing to do is to convert everything to UTC before storing in the database. Then when rendering a particular user's calendar, convert it to their local time for the purposes of display only.

When the user does anything date related, the backend should always be working on UTC, only ever taking into account the offset when it's time to print something to the user.

Doing it this way means you will very rarely have to worry about time zones, and checking conflicts is really simple. If a user on +6 hours looks at a user's schedule on -5 hours, the interface should ideally show the event over the time adjusted to the viewing user's time. This means an all day event in London would run from 5:00am - 4:59:59.999pm when viewed in a +5 time zone. It's no good to the person in a different time zone if his calendar shows the event over two whole days, or over one (incorrect) day as if he needs to call or be involved somehow, he may easily miss it.

EDIT

Thanks to @Blrfl for linking to it, but many DBMS's have excellent support for time zone operations built in so you might not want to do what I suggested. As for displaying it, I would still recommend displaying it as overlapping days, especially if other user's events from various timezones will be displayed on the same calendar.

Improve this answer
2
  • 1
    See this answer for a couple of reasons why normalizing to a single time zone isn't necessarily a good idea.
    – Blrfl
    Commented Sep 8, 2015 at 18:41
  • Hmm, that raises some good points and definitely makes sense (assuming your chosen DBMS is built for it). Reinventing the wheel can occasionally be useful though, but I suppose it depends on use case and chosen DBMS.
    – leylandski
    Commented Sep 9, 2015 at 10:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.