Certain NSDate constructors return a special NSConstantDate class which currently ends
up being unformatted as it's not in the list of supported classes for the NSDate formatter.
This patch adds that class to the supported class list so LLDB produces a summary for it.
One of these special constructors is [NSDate distantPast] which returns the date for
0001-01-01 00:00:00 UTC. LLDB has a special case for formatting this date but for some
reason we did hardcode the wrong summary string in that special case. Maybe the summary
string was correct back when the code was written but it isn't correct anymore (distantPast
isn't actually defined to be a special date but just some 'a guaranteed temporal boundary.' so
maybe someone changed the value in the last 10 years).
If someone else is wondering why we even have this special case for distantPast but not for
the future. The reason seems to be that our date formatting for really old dates is off by 24
hours. So for example, adding one second to distantPast will cause LLDB to print
0000-12-30 00:00:01 UTC (which is 24 hours behind the expected result). So to make
our code appear to be correct it seems we just hardcoded the most common NSDate result
from that time span. I'll replace that logic with a generic solution in a probably more invasive follow up patch.
I also took the freedom to replace the magic value -63114076800 with some constant
+ documentation. I heard there are some people that don't know from the top of their head that there
are 63114076800 seconds between 1. Jan 0001 and 1. January 2001 in whatever calendar system
NSDate is using.
Can't we get that value programmatically ?