[OptionOfT]

Weirdly enough an all day event in Office 365 isn't an all day event on a day.

E.g, I record my wife's birthday in my calendar.

I create an event on April 12th, and mark it as an all day event.

What actually happens is that the calendar records an event that starts at midnight, and ends 24 hours later, and is marked as an all day event.

But, when you change timezones the 24 hours actually shift, which can be very weird when you get notifications that are 6 hours earlier.

[godelski]

Sounds like something that could be solved by a flag.

  if all_day_event:
     show_option("timezone invariant")

If it is timezone invariant, then you can make it the 24hr (or whatever because there might not be 24 hrs in a day...) period relative to the current timezone.

This isn't an unsolvable problem, it is just people not seeking solutions.

I have a theory: a lot of tech products suck today because either:

  - People are not dogfooding[0] (using their own products)
  - People are not raising concerns
  - People raise concerns but issues are de-prioritized in favor of more flashy things. 

None of these things are great and they can only happen while a company has significant marketshare and monopoly like status. In essence, it is internal rot. Someone (plural) is disconnected from the actual product. They are out of touch with what the users want.

And I mean here's the thing. I could go ahead and write a wrapper for all of this and wrap in all my calendars. But that's a ton of work, there's probably no market, but if there was a market then the realistic result is that my success would result in the big players implementing the same feature and thus devaluing my work even though I increased the value of theirs. So I can do this as an open source project, but boy are there a lot of other higher priority issues like this. The real problem is that these issues can't be resolved within these big companies.

For whatever reason that is, it is bad business.

[0] https://en.wikipedia.org/wiki/Eating_your_own_dog_food

[thih9]

> make it the 24hr (...) period relative to the current timezone

What if the event gets shared - should the dates still be relative to the timezone of the creator? Or to the most popular timezone? Or should they be different for everyone? Or something else?

What if the event is recurring and the creator travels between the occurrences, should the times change? When should the times be updated? Should all events change, or only the future events, or only the closest one?

What if a participant uses multiple devices in multiple timezones at the same time?

…etc. Perhaps there are ways to solve all these and more; my point is that in the context of calendars even adding a flag can get complex fast.

[godelski]

  > What if the event gets shared - should the dates still be relative to the timezone of the creator?

You mean

  What if the event gets shared with someone who doesn't have a calendar that implemented this hypothetical yet super basic and highly useful feature.

Well then, it falls back to the standard 24 hr block, right? Yeah, it would be the timezone that it is currently being shared from because our flag was just telling the event to move itself with the timezone instead of being static.

Is that really that bad? This doesn't sound like a reason not to do this. Because the worst case scenario is that... we end up with the current implementation...

  > What if the event is recurring and the creator travels between the occurrences

Here's some shitty pseudocode. You could do this and store as UTC time but I think storing with timezone makes the point clearer.

  class Date(...):
      def __init__(self,
                   year   : int = 1970,
                   month  : int = 1,
                   day    : int = 1,
                   hour   : int = 0,
                   minute : int = 0,
                   second : int = 0,
                   ...
                   tmz    : str = "PST",
                   **kwargs):
          super().__init__()
          ...

      def start_of_day(self):
          self._hr, self._minute, self._second = self._sod

      def end_of_day(self):
          self._hr, self._minute, self._second = self._eod

  class Event(...):
      def __init__(self, 
                   start_time    : Date,         # date event begins
                   end_time      : Date,         # date event ends
                   all_day_event : bool = False, # is all day event 
                   tmz           : str = "PST",  # timezone
                   tmz_invar     : bool = False, # timezone invariant
                   **kwargs):
          super().__init__()
          ...
          self._begin = Date(start_time, tmz=tmz).start_of_day()
          self._end   = Date(end_time, tmz=tmz).end_of_day()
          if all_day_event:
             self._begin = self._begin.start_of_day()
             self._end   = self._end.end_of_day()
          self._ade = all_day_event
          self._tmz_invar = tmz_invar

  class Calendar(...):
      ...
      def display_events(self, ...):
         ...
          for event in self.events:
              if event.timezone_invariant:
                  self.display(event._begin._sod,
                               event._end._eod)
              else:
                  self.display(event._begin.tmz_offset(self.current_tmz),
                               event._end.tmz_offset(self.current_tmz))

All day events are marked as starting at the beginning of a day and ending at the end of a day. That being from our Date structure, which holds Month, Day of month, hour, minute, second, whatever precision, as well as special things like when the beginning of the day is and when the end of the day is. Here the function start_of_day() and end_of_day replaces whatever input values for {hour, minute, second, ...} with the appropriate values and attributes _sod and _eod are those values.

This assumed you stored events as a time with a timezone. If you stored events in UTC you'd need different logic. I mean time is messy, but either way we're moving stuff around. I mean we're just _displaying_ offsets when moving timezones, right? Because it would be wild to update all events every time we moved timezones, right? So we have to do some logic to take the date and display it relative to its time

With a timezone invariant flag all we're doing is saying

  Look at the year, month, and day. Ignore time and instead, use the day's start time and end time. 

  > What if the event is recurring and the creator travels between the occurrences, should the times change?

No, IT IS AN ALL DAY EVENT

  > When should the times be updated?

They don't, IT IS AN ALL DAY EVENT

  > What if a participant uses multiple devices in multiple timezones at the same time?

Doesn't matter, IT IS AN ALL DAY EVENT

I'll raise you a question

  What do you do if this is not an all day event and is in a specific time?

Think about that answer.

It is really not a hard problem. Because you are storing the events in some database. Moving timezones is then a conversion process. The invariant flag is just saying "keep the time relative to the day."

  > my point is that in the context of calendars even adding a flag can get complex fast.

I don't disagree, but I'm failing to see where this specific issue is an actual problem.