How do apps that work with splitting data into days deal with timezone changes?

Let's say an app tracks the number of times you blessed people sneezing during each day.

Now this app scores you every day after the day is over based on the proportion of blessed sneezes versus unblessed sneezes. Let's say you get a little prize on the day that you get 90%+ bless success rate.

But then what happens if you log as a sneeze at 2am on the 23rd of March and you fly across the world into a different timezone and its 11pm on the 22nd of March? Now suddenly you're logging sneezes for the previous day in local time. Now you're modifying the score for a day that already passed in the timezone you were previously in and already have a score for.

Every solution I can think of to this issue has major drawbacks.

For example, if you store every sneeze event in UTC and have the display adjust according to the new timezone, that might change previous daily scores. All the sneezes would be offset, and so some of your rewards might be retroactively retracted.

If instead you associate a sneeze with the Date (eg, 22/03/2023), then when you fly to another timezone, that day might go back one.

It seems impossible to solve. Yet, it must be something that many app developers encounter as there are many apps that fit this theme (e.g. Duolingo).

How can this problem best be approached?

Travelling from one timezone to another during day light saving is not a common use case. You should design your system for the majority of use cases (to keep the system as simple as possible) and then iteratively refine the handling of the edge cases based on the input of product people.

Also please bear in mind each and every design decision comes with a sacrifice. In order to better support X quality attribute you might "cause harm" on Y quality attribute. Based on the requirements you should do a trade-off analysis against the viable options. You should choose that alternative where the trade-off is acceptable from technical and business perspective as well.

UPDATE #1

> Any time you travel to a different timezone (e.g., from USA to England), your local time on your phone will change. Your apps will have to deal with this change in some way. For apps that have "daily records" and such, they would have to have to a way to deal with the change. My question was what the standard approach to solving this problem is with popular applications.

From the reported event perspective it does not matter that you are in which timezone. The following events happened in the exact same time

The offset is stored to be able to display events in the local time. From daily aggregate perspective the UTC matters only.

UPDATE #2

Based on the new comments I assume we are talking about late events. From the processing perspective a given event arrived later than expected. In case of stream processing we usually have windows. A late event arrived in W_T+1 but it belongs to W_T. In this case we have a grace period until we have the willingness to recompute the W_T. For instance if you create new tumbling windows in every minute then the grace period could a half minute.

You have used the term daily report. Based on that I assume that here we are talking about batch processing rather than stream processing. Let's say we calculate the previous day's daily reports at 3am. In this case we already have grace period with 3 hours.

Let's say the batch processing is already done but we still receive new events which should indicate re-processing. Here you have multiple options, here are the two most common:

• Flag / Queue those jobs which needs to be reprocessed
• Update the accumulated value as new events arrive

The latter one could only work if we can assume the followings:

• There is a method which can be used to calculate the new aggregate from the already accumulated data and a new event
• The method is not computation and/or resource heavy
• The anticipated late arrivals volume is considered low
• etc.

The former one assumes less things. When a new event arrives which induce the reprocessing of a finished job then we should mark that job as dirty. Either by flagging the job or by putting the job's id into a reprocess queue or ... The main point here is that you support a reprocessing but only once (at end of the grace period).

If you have done the first batch processing at 3am you can do the second at 8am for instance. Which is a trade-off of course (timelines vs accurateness). In a rewarding system, like the one you mentioned, the achievement / trophy would appear on the user's profile at the end of the second processing. (You can see the same delayed badges here at StackOverflow.)

Yet another alternative could be to perform regional batch processing. Rather than computing all the reports at the exact same time, different data centres can do it in their local 3am. This follow the sun strategy works well if your customers are also region-aware.