Best code strategy here is twofold.
1. Maximize the code context where date/time is represented as a simple count of Unix epoch seconds.
2. Never pass calendar/clock representations through API methods.
3. Always pass a timezone to methods that require it.
4. Counting, like time, is hard.
The only contexts I see where calendar/clock representation are needed are:
- Accept calendar/clock info from the user or external data sources.
- Present calendar/clock info to the user or external data sources.
- Internal "calendar aware" operations (find the Unix epoch second count "one month from now").
These all require a timezone to be specified. They may still be a mess internally but their operation is unambiguous. They may use imperfect data types like datetime but the issues of these data times are confined to their internal code context.
1. Maximize the code context where date/time is represented as a simple count of Unix epoch seconds.
2. Never pass calendar/clock representations through API methods.
3. Always pass a timezone to methods that require it.
4. Counting, like time, is hard.
The only contexts I see where calendar/clock representation are needed are:
- Accept calendar/clock info from the user or external data sources.
- Present calendar/clock info to the user or external data sources.
- Internal "calendar aware" operations (find the Unix epoch second count "one month from now").
These all require a timezone to be specified. They may still be a mess internally but their operation is unambiguous. They may use imperfect data types like datetime but the issues of these data times are confined to their internal code context.