Could you elaborate on what you mean? I think it's already impossible to accurately turn a future timestamp into a local time, leap seconds or not, because of timezone shenanigans. So I'm probably misunderstanding what you're talking about.
I think it depends on whether you consider “localized” to refer to a point in time in a particular time zone, or to a point in time in a particular physical location.
> or to a point in time in a particular physical location
But how does this not take the local time zone into account? For "time at location", the local time zone is by necessity always involved in conversions, isn't it? There's just a difference between the time zone being explicit in your data representation, or merely implied.
But you cannot with any sort of confidence assume a future "implied" time zone, which makes turning a future timestamp into a local time, even using a timezone-naive representation, into an usure proposition.
Maybe I'm simply not aware of specific conventions around this topic, though, hence my original question.
Oh I'm saying the reverse, I think. Future timestamp for "time at location" is impossible because you don't know within which time zone a location will be in the future. But for the right time zone database structure you can have indeterminate time zones - so you can know future timestamps for a time zone, but you don't know if any particular location (or any location at all) is using that time zone in the future.
Could you elaborate on what you mean? I think it's already impossible to accurately turn a future timestamp into a local time, leap seconds or not, because of timezone shenanigans. So I'm probably misunderstanding what you're talking about.
I think it depends on whether you consider “localized” to refer to a point in time in a particular time zone, or to a point in time in a particular physical location.
> or to a point in time in a particular physical location
But how does this not take the local time zone into account? For "time at location", the local time zone is by necessity always involved in conversions, isn't it? There's just a difference between the time zone being explicit in your data representation, or merely implied.
But you cannot with any sort of confidence assume a future "implied" time zone, which makes turning a future timestamp into a local time, even using a timezone-naive representation, into an usure proposition.
Maybe I'm simply not aware of specific conventions around this topic, though, hence my original question.
Oh I'm saying the reverse, I think. Future timestamp for "time at location" is impossible because you don't know within which time zone a location will be in the future. But for the right time zone database structure you can have indeterminate time zones - so you can know future timestamps for a time zone, but you don't know if any particular location (or any location at all) is using that time zone in the future.
Leap seconds are not deterministic.