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
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.