Arc stores each recorded sample’s offset from UTC at time and location of recording. Samples are recorded every 2 to 60 seconds, so the timezone data is very granular.
That solves the data accuracy problem, and from there the rest is up to how you display it in the UI. At the moment Arc displays start and end times for TimelineItems in the timeline view based on the first and last sample within the item. So if the item started in one timezone and ended in another, the start time will be shown appropriate to the start timezone and end time appropriate to the end timezone.
Oh yeah that’s a curious one. Off the top of my head I can’t remember how the UI decides the boundaries for a single day’s timeline view. Lemme check… Ok, found it. It’s delegating the job to the iOS Foundation Calendar class, which means deferring to the expertise of calendar/date professionals, and letting them take the heat instead
It uses Calendar.current.dateInterval(of: .day, for: date), which… ok, that might mean it’s using current local timezone, due to the Calendar defaulting to that. The question then is, is that the right or wrong thing to do. My gut instinct says probably wrong. But the alternative would be to use the timezone of … the most common timezone of the samples within the range? Ugh, there it starts to get a lot more complex. And would result in potentially swiping back and forth between days that are significantly longer or shorter than 24 hours. Which then also intuitively falls into the “that’s wrong” bucket. There’s no easy answers