What is the (best) way to handle dates before Christ in C#/.NET?

前端 未结 3 909
失恋的感觉
失恋的感觉 2020-12-11 00:59

Is there any built-in support for that? And if not, is there any consensus about handling such dates?


Links to owncoded solutions, or fragments of it, are very

相关标签:
3条回答
  • 2020-12-11 01:04

    If you're referring the handling of DateTime values < DateTime.MinValue, then I think the only "consensus" is to not use System.DateTime to try to represent them.

    Any consensus would likely exist only within a community that does work with such dates. What is the area in which you are working? Astronomy?


    Whatever the area of interest, there are likely to be others who have experienced this same problem. I'd do some research first, especially if your dates will ever need to interoperate with other software in this same area of interest. Even if you have to code your own, you can at least become aware of the issues that others have had in coding their own.

    0 讨论(0)
  • 2020-12-11 01:25

    I know this question is old but I found it in a search and can add additional insight to this topic. In the comments above, someone posited that the date difference would be greater than 1 year. Unless one is planning to go back to a time well before exact dates can be usefully derived (many thousands of years), that is not the case. The differential needed for both Julian dates & Gregorian dates is only a small number of days, certainly less than 3 weeks for any specific date one could reasonably attempt to derive from extant historical records. There are conversion tables for this purpose. I believe the greater problem comes from the conversion to the Gregorian calendar.

    Different countries converted at different times and they lost different numbers of days when they converted because they did not convert at the same time. For an example of how the conversion occurred, imagine today is October 1 and tomorrow will be October 10. In that scenario, the conversion would lead to a loss of 9 days in that particular country. Another country which converted some time later may have lost 11 days, or 12 days, or 13 days, etc. Another big problem would be attempting to derive the season on a particular date. Due to inexact calendars, precession of the equinoxes resulted in a somewhat rapid progression of the seasons through the calendar year over time. Today we have summer in the northern hemisphere during the month of July. 3000 years ago, this calendar month may have occurred during the middle of winter if we are using the Julian calendar as our standard.

    It's also important to note that a wide variety of ancient calendar systems were used in the ancient world. Both solar and lunar varieties existed and there was no realistically effective attempt at standardization until about 2000 years ago (when the Julian calendar was invented). People frequently try to project Julian dates much further back into history but those efforts are anachronistic. Due to the uncertainty caused by inconsistent records, it is not possible to determine a particular event occurred on a specific date correlated with the Julian calendar, except in a round-about way which involves a rather large margin of error. For an event occurring prior to the first millennium BC, that margin of error may be 50 or 100 years (or more in certain periods). We simply don't have the records to establish an extremely accurate timeline. Carbon dates derived from tree ring sequences correlated with extant records have helped to shrink the margin of error in various regions and periods but they do not compose a completely connected record and we will always have a margin of error to deal with.

    0 讨论(0)
  • 2020-12-11 01:27

    There is no built in support for dates in this range so you will have to code your own.

    Here is an example http://flipbit.co.uk/2009/03/representing-large-ad-and-bc-dates-in-c.html.

    0 讨论(0)
提交回复
热议问题