>If you need to save a future datatime which is not UTC, [...] a struct with an unambiguous, validated datetime and the timezone along with it.
It's less ambiguous but it's not 100% unambiguous because future policies of Daylight Saving Time and Time Zone / Time offset boundaries can be changed by governments.
Even if the struct had extra fields for flags such as "obey future DST changes" or "ignore present TZ if different from historic TZ at time of data entry", it's still ambiguous if geographic coordinates are not embedded within the struct. Then again, there's probably some more edge cases even with latitude/longitude coordinates. (E.g. should the future time be interpreted at lat/long of where he data-entered the datetime, or the lat/long of where he later experiences the datetime?!)
Dates specifying future events are very tricky++. Unless, it's a future date for something celestial such as a solar eclipse; in such cases, a future date as UTC is unambiguous.
++Because we all conflate concepts of "socially-constructed future datetime as shown on a wall clock" and "scientific future datetime". We stuff both concepts into the same data structures. Nevertheless, we write software that makes educated guesses about the user intentions for "future dates" and it works for 99% of the typical use cases. (e.g. "send smartphone notification for 12:30 lunch with Bob next week.)
Right, it is unambiguous for the current rules and zone. Usually if the rules change, you want to do the calculation again. I made a library for persisting future DateTimes to a database. Whenever a DateTime is loaded from the database, the calculation is done again. A blog post about it can be found at http://www.creativedeletion.com/2015/03/19/persisting_future...
If the "borders of the timezones" change, that does not make it unambiguous, because the struct is defined as belong to a timezone name, not a specific geographical location.
What I find missing from most, if not all, date/time libraries is a three-arg timezone conversion function (i.e. one that is pure and doesn't rely on the current time or locale). Most timezone conversions take a zoned date and time and convert it to a different timezone. But it matters when/where you're doing the conversion for the reasons you're discussing. If you also supply a UTC timestamp indicating when the conversion should take place (note, not a zoned date and time, since the conversion to the universal timeline can be affected by DST changes), that conversion can be consistent no matter when/where the function runs.
I find this approach to be cleaner than saving wall time since it allows you to keep uniform times on the server and simplify server-side logic that acts on those times in bulk.
If the "borders of the timezones" change, that does not make it unambiguous, because the struct is defined as belong to a timezone name, not a specific geographical location.
The "TZ name" designation can change for a location so even if you store it in the struct, it's still ambiguous. It's not a common occurrence but it has happened before. It is impossible to store a 100% unambiguous socially-constructed future datetime that works for all edge cases.
To clarify, I'm not saying your datetime library is "incorrect" or needs to change. I'm just pointing out that your guarantee about it recording an "unambiguous future date" is not possible to achieve for all edge cases.
Comments
>If you need to save a future datatime which is not UTC, [...] a struct with an unambiguous, validated datetime and the timezone along with it.
It's less ambiguous but it's not 100% unambiguous because future policies of Daylight Saving Time and Time Zone / Time offset boundaries can be changed by governments.
Even if the struct had extra fields for flags such as "obey future DST changes" or "ignore present TZ if different from historic TZ at time of data entry", it's still ambiguous if geographic coordinates are not embedded within the struct. Then again, there's probably some more edge cases even with latitude/longitude coordinates. (E.g. should the future time be interpreted at lat/long of where he data-entered the datetime, or the lat/long of where he later experiences the datetime?!)
Dates specifying future events are very tricky++. Unless, it's a future date for something celestial such as a solar eclipse; in such cases, a future date as UTC is unambiguous.
++Because we all conflate concepts of "socially-constructed future datetime as shown on a wall clock" and "scientific future datetime". We stuff both concepts into the same data structures. Nevertheless, we write software that makes educated guesses about the user intentions for "future dates" and it works for 99% of the typical use cases. (e.g. "send smartphone notification for 12:30 lunch with Bob next week.)
Right, it is unambiguous for the current rules and zone. Usually if the rules change, you want to do the calculation again. I made a library for persisting future DateTimes to a database. Whenever a DateTime is loaded from the database, the calculation is done again. A blog post about it can be found at http://www.creativedeletion.com/2015/03/19/persisting_future...
If the "borders of the timezones" change, that does not make it unambiguous, because the struct is defined as belong to a timezone name, not a specific geographical location.
What I find missing from most, if not all, date/time libraries is a three-arg timezone conversion function (i.e. one that is pure and doesn't rely on the current time or locale). Most timezone conversions take a zoned date and time and convert it to a different timezone. But it matters when/where you're doing the conversion for the reasons you're discussing. If you also supply a UTC timestamp indicating when the conversion should take place (note, not a zoned date and time, since the conversion to the universal timeline can be affected by DST changes), that conversion can be consistent no matter when/where the function runs.
I find this approach to be cleaner than saving wall time since it allows you to keep uniform times on the server and simplify server-side logic that acts on those times in bulk.
The "TZ name" designation can change for a location so even if you store it in the struct, it's still ambiguous. It's not a common occurrence but it has happened before. It is impossible to store a 100% unambiguous socially-constructed future datetime that works for all edge cases.
To clarify, I'm not saying your datetime library is "incorrect" or needs to change. I'm just pointing out that your guarantee about it recording an "unambiguous future date" is not possible to achieve for all edge cases.