> > As for years BC, <-0001-...> will be a breaking change. But I do not > > think that we need to really worry about this. Not unless we actually > > get feature request. What is the practical application?
Using org as a format for writing about history and being able to reference dates in the past accurately and have the dates be first class entities that can be parsed and checked etc. The example in my head is a history professor who wants to write about e.g. the collapse of the Roman republic and not have to come up with their own time keeping system or force any one who wants to work with referenced dates to do a bunch of math to translate from a roman time system to a modern one. > Given that the stated approach is to leverage off OS facilities in this > area, it probably should also be noted that some OSs don't handle > historical dates, especially BC ones, at all well. For example, some OS > use a 32 bit number to represent the date+time and can really only > handle dates between approx 1900 and 2038 (or around there - cannot > remember specific range). So with respect to timestamps and time related > calculations, we are limited by the capabilities of the least capable > supported OS. I'm mostly concerned about the syntactic features where org already supports dates well outside the facilities of various operating systems. I don't think that it is wise or practical for org-mode code to use anything other than the os provided time keeping facilities right now, but it is important to enable people who might want to do so. Org as a format for documents has a wider range of use cases for dates and times than Org as a life organizer and planner. At the same time those wider use cases don't always need as much precision or ux considerations because I don't think anyone using org right now is going to be early or late to their meeting at [3023-01-16 Thu 12:00] (regardless of the timezone). But org does tell me that it will be a Thursday! Best, Tom