We Keep Coding

Can DateTime represent a date before Christ / before our time? or How is this managed?

So, I noticed DateTime.MinValue defaults to 01-01-0001 (dd-MM-yyyy), so for example let's say we have a museum database/class object whatever, how do you store an object that is from 10,000 BC or how about dinosaur bones that are from millions of years prior to today?
Can it be a signed value? like, the year "-10000" represents BC?
or we would need to rely on strings and be unable to natively work with dates prior to year 1?
I checked this question out that asks for year zero, but it doesn't have any helpful insights, other than apparently not everyone knows there is no such thing as year zero. how make a datetime object in year 0 with python

No, DateTime doesn't handle anything before 1CE.
My Noda Time project does support BCE dates, but still limited to about 9998 BCE as the earliest it can handle.
Once you're talking about prehistoric times, you probably have a different set of use cases from normal date/time types anyway - so just extending the range of the existing types may well not help you much. (As an example, quite often ancient history deals with relative dates: "I know battle X took place 3 years into the reign of king Y, but I don't know exactly when either of them happened.") I'd suggest you think about what your actual use cases are, and what you need to do with the date/time information. Then you can look into whether existing libraries meet your needs, or whether you need to write your own abstractions.

After digging around, I've found that other than creating one's own types, there is no easy native solutions to this specific use case for dates, so I want to propose my solution in case its of use to anyone. Just add a column that will have a sign, a - and a + (or a 0 and 1 I guess with a boolean type). Dates with + are AC and dates with - are BC. On your code or otherwise you'll have to handle the sign. Its simple and requires no extra libraries or technologies.
Since dates have no zeros the sign should not create interference, and just minding negative dates move in reverse order in your logic will solve any issues with that. However this solution only works for dates up to year 9999, so in order to be able to handle even farther away dates, a more complex sistem would have to be programmed. like handling each part of a date in a separate column so it can cover as many years as int or double can do numbers.
However, I do think positive dates from the year 3000 up to the year 9999 will hardly ever be used, much less towards millions of years into the future. But maybe it will be of use for fan proyect databases for sci-fi universes like 40K or SW or ST.

NodaTime and Ancient Times

I'm working with some values from WikiPedia that are in some cases Million of years ago (Like the formation of the moon, which WikiData reports as being formed: "-4527000000-01-01T00:00:00Z". In other case I'm simply looking at years that might be 10000 B.C. etc., still expressed as "-10000-01-01T00:00:00Z".
As far as I could figure out testing NodaTime, and reading the documentation, these ancient years are not supported (OR I overlooked something). For example, this fails:
OffsetDateTime defaultValue = new OffsetDateTime(new LocalDateTime(77, 1, 1, 0, 0), Offset.Zero);
var pattern = OffsetDateTimePattern.Create("yyyy-MM-ddTHH:mm:ss'Z'", CultureInfo.InvariantCulture, defaultValue);
string P = "-1000-01-25T20:34:25Z";
var result = pattern.Parse(P);
NodaTime.Text.UnparsableValueException: The value string includes a negative value where only a non-negative one is allowed. Value being parsed: '^-1000-01-25T20:34:25Z'. (^ indicates error position.)
at NodaTime.Text.ParseResult`1.GetValueOrThrow() in C:\Users\jon\Test\Projects\nodatime\build\releasebuild\src\NodaTime\Text\ParseResult.cs:line 81
at TryNodaTime.Program.Main(String[] args
using sing this string works fine btw: string P = "1000-01-25T20:34:25Z";
I'm hoping I just overlooked something obvious as to handle very large old dates/years. Other examples includes old cities btw, which have exact date from long before year 0.
Guidance on how to handle these would be greatly appreciated.
EDIT: Found this example, which requires me to first detect the year manually, and then use LocalDate if it's negative, however, doesn't solve the larger issue here as it fails below -9999:
LocalDate BCDATE = new LocalDate(Era.BeforeCommon, -15000, 10, 1);
Console.WriteLine($"BC: {BCDATE}");

Noda Time doesn't support ancient or far future values.
The range of values supported is in the user guide.
Noda Time can only represent values within a limited range. This is for pragmatic reasons: while it would be possible to try to model every instant since some estimate of the big bang until some expected "end of time," this would come at a significant cost to the experience of the 99.99% of programmers who just need to deal with dates and times in a reasonably modern (but not far-flung future) era.
The Noda Time 1.x releases supported years between around -27000 and +32000 (in the Gregorian calendar), but had significant issues around the extremes. Noda Time 2.0 has a smaller range, with more clearly-defined behaviour.
...
Additionally, all calendars are restricted to four digit formats, even in year-of-era representations, which avoids ever having to parse 5-digit years. This leads to a Gregorian calendar from 9999 BCE to 9999 CE inclusive, or -9998 to 9999 in "absolute" years. The range of other calendars is determined from this and from natural restrictions (such as not being proleptic).
I'm afraid I think it may well be better not to use Noda Time at all for this use case, rather than trying to work around it - unless you're okay with effectively reporting the far-distant dates verbatim and doing no other work with them.
Sorry about this - it's one of those situations where trying to support all use cases does harm to the far more common use case :(

How do I accurately represent a Date Range in NodaTime?

Goals
I have a list of LocalDate items that represent sets of start dates and end dates.
I would like to be able to store date ranges, so that I can perform operations on them as a set of overlapping or distinct ranges, etc.
Questions
Does NodaTime provide some sort of DateRange construct that I've missed in the docs?
Am I thinking about this wrong? Is there a more natural / preferred way to accomplish this that NodaTime already allows for?
Am I setting myself up for trouble by attempting to think about a date range using a LocalDate for a start and an end date?
I'm completely new to NodaTime and assuming that this is a conceptual misunderstanding on my part.
Update: I noticed a similar question on the subject from 2009, but that seems to refer to another utilies class; I'm assuming that since then NodaTime may have evolved to accomodate this situation.

Noda Time provides an Interval type for a range of Instant values, but it doesn't provide range types for the other types. Part of the reason for this is the nuance of how ranges are used for different types.
If I give you a range of instants, it is always treated as a half open interval. The start value is included, but the end value is excluded. Humans do this naturally any time we provide a time value, such as when I say an event runs from 1:00 to 2:00, clearly I mean that the event is over at 2:00, so 2:00 is excluded.
But with whole calendar date ranges, typically the end dates are inclusive. To represent the entire month of January (as a range of LocalDate values), I would probably say Jan 1st through Jan 31st, and I am including the last day in its entirety.
We could probably add some additional range types to enforce these things, but we would need to think about how much value there is in having them in the API when you could probably just create them as needed. I'm not saying I'm for or against it either way, but that's probably something to be debated on the Noda Time user group.
To answer your specific questions:
No, there is no predefined range class for local dates.
The only other thing to consider is that calendar math is usually done via the Period class. For example, to determine how many days there are between two calendar dates:
LocalDate ld1 = new LocalDate(2012, 1, 1);
LocalDate ld2 = new LocalDate(2013, 12, 25);
Period period = Period.Between(ld1, ld2, PeriodUnits.Days);
long days = period.Days;
No, there's nothing wrong with creating a range class of local dates, there just might not be a whole lot of advantage. You may do just as well by having two properties, StartDate and EndDate, on your own classes. Just be careful about the inclusiveness of the end dates, vs the exclusiveness you'd see with an interval or time range.
And lastly, you said:
... so that I can perform operations on them as a set of overlapping or distinct ranges, etc.
You're probably looking for operations like intersection, union, calculating gaps, sorting, etc. These and more are defined by the Time Period Library, but Noda Time doesn't currently have anything like that. If one was to create it, it should probably be in a companion library ("NodaTime.Ranges", perhaps?). Likely it wouldn't be desired to pull it into the core, but you never know...
If you do end up using that Time Period Library, please make sure you recognize that it works with DateTime only, and is completely oblivious to DateTimeKind. So in order to be productive with it, you should probably make sure you are only working with UTC values, or "unspecified" calendar dates, and try not to ask it things like "how many hours are in a day" because it will get it wrong for days with daylight saving time transitions.

C#, WCF and DateTime.MinValue() vs. Null Date

I have searched around but have yet to find a satisfying answer for my issue:
Overview: I am working on a small app that uses several DateTime fields into a single table using WCF. We are trying to eliminate null fields in all of our tables. Up until now, whenever we are converting a datetime field selected from a table we first verify that it is null before we display or otherwise "use" it. If the value is NULL, we substitute DateTime.MinValue for the value. Since we are now removing the nullable aspect of all fields, we need to insert a common value representing null; since DateTime.MinValue() is substituted everywhere in the code, it seems like a viable value to put into the field as a null substitute.
The problem: Inserting a DateTime.MinValue() causes the generic "problem executing this request" error.
Solution? : As has been documented elsewhere, the DateTime.MinValue() has an unspecified DateTimeKind so... we add the ToUniversalTime call, as in :
DateTime nullDate = DateTime.MinValue.ToUniversalTime(); // 1/1/0001 6:00:00 AM
This doesn't work, perhaps because of some "acceptable range" setting within Date conversions on WCF?
Noted in the comment is the resulting value of "1/1/0001 6:00 am". The odd 6:00am or the year "1" aside, that seems fine. (Considering the past of default years like 12:00 AM 1970 are still fairly standard, but I digress...)
Yes, I know that DateTime is not C#, it's .NET. I'm also aware that WCF has some form of "min" and "max" times allowed within its conversion constraints. I don't know how to set those (nor do I know how to set the VerboseMessages bit; I'm fairly new to WCF.)
The suggestion to manually create a new field value that converts nicely into the table is viable, and it works:
DateTime nullDate = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
(BTW, If we use the year 1 instead of 1970 (for example) the insert will also fail.)
Even if we were to use the above nullDate as a workable substitute... the problem is that everywhere in the code we are still evaluating against DateTime.MinValue() representing a null date, and those two dates aren't quite the same.
The only viable solution that I can think of is to override or otherwise create an extended class from DateTime to create a common NullDate and modify all the code accordingly.
Does anyone see a good alternative? Does anyone know a solution to inserting the System.DateTime.MinValue() into a WCF table such as altering the acceptable boundries of a good/bad date?
I feel like I'm going to have to bite the bullet and change all references to MinValue... I'm trying to avoid that because it doesn't follow any sort of standard logical thought in evaluating "default" values.
Suggestions anyone?

It depends on the database you are using to store the data. SQL Server, for example, has a minimum date of 1/1/1753, see MSDN. I am not sure about Oracle.
If you Have to use a magic date, you can use that, or something else specific (I use 10 December 1815 in honor of the Lady Ada Lovelace, the first programmer). Generally speaking, if you have a situation where you have no known value, the data store should represent the value as 'null.' Now in practice, that's not always viable. What you could do is refactor the nullable columns into a subtable, and only include a child record when you in fact have something to record.

How to design Date-of-Birth in DB and ORM for mix of known and unknown date parts

Note up front, my question turns out to be similar to SO question 1668172.
This is a design question that surely must have popped up for others before, yet I couldn't find an answer that fits my situation. I want to record date-of-birth in my application, with several 'levels' of information:
NULL value, i.e. DoB is unkown
1950-??-?? Only the DoB year value is known, date/month aren't
????-11-23 Just a month, day, or combination of the two, but without a year
1950-11-23 Full DoB is known
The technologies I'm using for my app are as follows:
Asp.NET 4 (C#), probably with MVC
Some ORM solution, probably Linq-to-sql or NHibernate's
MSSQL Server 2008, at first just Express edition
Possibilities for the SQL bit that crossed my mind so far:
1) Use one nullable varchar column e.g. 1950-11-23, and replace unkowns with 'X's, e.g. XXXX-11-23 or 1950-XX-XX
2) Use three nullable int columns e.g. 1950, 11, and 23
3) Use an INT column for year, plus a datetime column for full known DoBs
For the C# end of this problem I merely got to these two options:
A) Use a string property to represent DoB, convert only for view purposes.
B) Use a custom(?) struct or class for DoB with three nullable integers
C) Use a nullable DateTime alongside a nullable integer for year
The solutions seem to form matched pairs at 1A, 2B or 3C. Of course 1A isn't a nice solution, but it does set a baseline.
Any tips and links are highly appreciated. Well, if they're related, anyhow :)
Edit, about the answers: I marked one answer as accepted, because I think it will work for me. It's worth looking at the other answers too though, if you've stumbled here with the same question.

The SQL Side
My latest idea on this subject is to use a range for dates that are uncertain or can have different specificity. Given two columns:
DobFromDate (inclusive)
DobToDate (exclusive)
Here's how it would work with your scenarios:
Specificity DobFromDate DobToDate
----------- ----------- ----------
YMD 2006-05-05 2006-05-06
YM 2006-05-01 2006-06-01
Y 2006-01-01 2007-01-01
Unknown 0000-01-01 9999-12-31
-> MD, M, D not supported with this scheme
Note that there's no reason this couldn't be carried all the way to hour, minute, second, millisecond, and so on.
Then when querying for people born on a specific day:
DECLARE #BornOnDay date = '2006-05-16'
-- Include lower specificity:
SELECT *
FROM TheTable
WHERE
DobFromDate <= #BornOnDay
AND #BornOnDay < DobToDate;
-- Exclude lower specificity:
SELECT *
FROM TheTable
WHERE
DobFromDate = #BornOnDay
AND DobToDate = DateAdd(Day, 1, #BornOnDay);
This to me has the best mix of maintainability, ease of use, and expressive power. It won't handle loss of precision in the more significant values (e.g., you know the month and day but not the year) but if that can be worked around then I think it is a winner.
If you will ever be querying by date, then in general the better solutions (in my mind) are going to be those that preserve the items as dates on the server in some fashion.
Also, note that if you're looking for a date range rather than a single day, with my solution you still only need two conditions, not four:
DECLARE
#FromBornOnDay date = '2006-05-16',
#ToBornOnDay date = '2006-05-23';
-- Include lower specificity:
SELECT *
FROM TheTable
WHERE
DobFromDate < #ToBornOnDay
AND #FromBornOnDay < DobToDate;
The C# Side
I would use a custom class with all the methods needed to do appropriate date math and date comparisons on it. You know the business requirements for how you will use dates that are unknown, and can encode the logic within the class. If you need something before a certain date, will you use only known or unknown items? What will ToString() return? These are things, in my mind, best solved with a class.

I like the idea of 3 int nullable columns and a struct of 3 nullable int in C#.
it does take some effort in db handling but you can avoid parsing around strings and you can also query with SQL directly by year or year and month and so on...

Whatever you do is going to be messy DB wise. For consumers of these kind of dates, I would write a special class/struct which encapsulates what sort of date it is (I'd probably call it something like PartialDate), to make it easier to deal with for consumers- much like Martin Fowler advocates a Money Class.
If you expose a DateTime directly in C#, this could lead to confusion if you had a "date" of ????-11-23 and you wanted to determine if the customer was over 18 for example- how would you default the date, how would the consumer know that part of the date was invalid etc...
The added benefit of having a PartialDate is it will allow other people reading your code to quickly realise that they are not normal, complete dates and should not be treated as such!
Edit
Thinking about the Partial data concept some more, I decided to Google. I found that There is the concept of Partial on Joda time and an interesting PDF on the topic, which may or may not be useful to you.

Interesting problem...
I like solution 2B over solution 3C because with 3C, it wouldn't be normalized... when you update one of the ints, you'd have to update the DateTime as well or you would be out of sync.
However, when you read the data into your C# end, I'd have a property that would roll up all the ints into a string formatted like you have in solution 1 so that it could easily be displayed.
I'm curious what type of reporting you'll need to do on this data... or if you'll simply be storing and retrieving it from the database.

I would not worry to much about how to store the date, I would still store the date within a datetime field, BUT, if knowing if some part of the date was not populated, I would have flags for each section of the date that is not valid, so your schema would be:
DBODate as Date
DayIsSet as Bit
MonthIsSet as Bit
YearIsSet as Bit.
That way you can still implement all the valid date comparisons, and still know the precision of the date you are working on. (as for the date, I would always default to the missing portion as the min of that value: IE Month default is January, day is the first, year is 1900 or something).

Obviously, all of the solutions mentioned above do represent some kind of compromise.
Therefore, I would recommend to think carefully which of the 'levels' is the most likely one and optimize for that. Afterwards go for proper exception handling for the other rare cases.
I don't know whether reporting is an issue for you right now or may be later, but you might consider that as third dimension apart from the DB / C# issues.