3 ms·

I recently built a small Python library to try getting time management right [1]. Exactly because of the first part of your comment, I concluded that the only w

I recently built a small Python library to try getting time management right [1]. Exactly because of the first part of your comment, I concluded that the only way to apply a time delta in "calendar" units is to provide the starting point. It was fun developing variable-length time spans :) I however did not address leap seconds. You are very right that future calendar arithmetic is undefined. I guess that the only viable approach is to assume that it works based on what we know today, and to treat future changes as unpredictable events (as if earth would slow its rotation). Otherwise, we should just stop using calendar arithmetic, but in many fields this is just unfeasible... [1] https://github.com/sarusso/Propertime https://github.com/sarusso/Propertime

miki123211 2y ago
> I guess that the only viable approach is to assume that it works based on what we know today, and to treat future changes as unpredictable events No, the only way is to store the user's intent, and recalculate based on that intent when needed. When the user schedules a meeting for 2PM while being in Glasgow, the meeting should stay at 2PM Glasgow time, even in a hypothetical world where Scotland achieves independence from the UK and they get different ideas whether to do daylight saving or not. The problem is determining what the user's intent actually is; if they set a reminder for 5PM while in NY, do they want it to be 5PM NY time in whatever timezone they're currently in (because their favorite football team plays at 5PM every week), or do they want it to be at 5PM in their current timezone (because they need to take their medicine at 5PM, whatever that currently means)?
- ForOldHack 2y ago
  And if the number of seconds changes, such as in a batch job on a super computer, you should adjust the time of the computer first, and then adjust the billing for the job , after it completes. I asked IBM if they quantium cloud could count the time in either direction... At first they were confused, but then they got the joke.

miki123211 2y ago

> I guess that the only viable approach is to assume that it works based on what we know today, and to treat future changes as unpredictable events No, the only way is to store the user's intent, and recalculate based on that intent when needed. When the user schedules a meeting for 2PM while being in Glasgow, the meeting should stay at 2PM Glasgow time, even in a hypothetical world where Scotland achieves independence from the UK and they get different ideas whether to do daylight saving or not. The problem is determining what the user's intent actually is; if they set a reminder for 5PM while in NY, do they want it to be 5PM NY time in whatever timezone they're currently in (because their favorite football team plays at 5PM every week), or do they want it to be at 5PM in their current timezone (because they need to take their medicine at 5PM, whatever that currently means)?

ForOldHack 2y ago
And if the number of seconds changes, such as in a batch job on a super computer, you should adjust the time of the computer first, and then adjust the billing for the job , after it completes. I asked IBM if they quantium cloud could count the time in either direction... At first they were confused, but then they got the joke.