Talk:Key:end date
Consider this tag rejected per same reasons as Proposed features/Status
Proposed features/Status was rejected and for the very same reasons this tag would be rejected if voted in near future. The problem with it is that software not aware of this special tag will erroneously consider objects long gone (and marked with end_date) as still existing and valid. If you think that it should not be so hard to teach software to learn end_date then consider that there are literally dozens of alternative proposals which would be also quite easy for software to learn if we would agree on one of them - but this one is one those one which causes most trouble.
See Comparison of life cycle concepts for alternatives which cause less trouble. RicoZ (talk) 21:44, 16 December 2014 (UTC)
Verifiable end dates in the future
If a train station has a posted sign saying the date when it will close for good, sometime in the future, why shouldn't it have an end_date=* tag? Of course, a note is also a good idea, to make sure mappers remember to delete the feature and move it to OpenHistoricalMap. But notes don't do any good for data consumers who extract OSM data in the meantime and use it for an indeterminate amount of time. – Minh Nguyễn 💬 18:18, 29 May 2023 (UTC)