Hello,
I have an app with deals with Julian and prejulian dates.
Now, let’s take these two snippets:
dim d as new date
d.Year = -1//that is 2 BC
d.Month = 4
d.Day = 3
d.TotalSeconds = d.TotalSeconds
and
dim dd as new date
dd.Year = 2
dd.Month = 4
dd.Day = 3
dd.TotalSeconds = dd.TotalSeconds
in the debugger, clicking “d” and “dd” I get the same value for year (year 2), and different values for totalseconds.
This makes things a little difficult to check dates at first glance, unless in System Preferences > Date I drop “era” in the various date-fields.
In such case the debugger shows respectively year 2 BC and year 2 AD.
But this step results in having all dates bear AD all over the system. Something --I guess-- nobody would like (while AM/PM in times makes sense).
Therefore, is it not possible to add “era” to the date object itself? So that the above code would look:
dim d as new date
d.era = 0//or whatever makes sense to mark BC from AD
d.Year = 1
d.Month = 4
d.Day = 3
d.TotalSeconds = d.TotalSeconds
so that in the debugger I’d see year 2 BC.
Or is there something I overlooked?
BTW: there is Cocoa.Calendar.NSEraCaldendarUnit, but I do not know whether it is relevant, and how I could possibly use it.
Thanks.
I believe this is not possible except for maybe a custom Date subclass that has a computed era-year property. Stackoverflow answers for macOS indicate that what you experience is standard System behavior. Keep in mind date is limited on Windows and you can only get back about 400 years when you use the date class here.
@Carlo Rubini You can create a new reference date for 01/01/01 00:00:00 (i.e. -60084547200.0 total seconds) and see if the TotalSeconds of your date is higher or lower. That will give you the era.
You also can implement it as an extension to the Date object, to make it more transparent
Actually I was referring to debugging situations, where similar d.totalseconds being pretty similar do not give a quick & friendly understanding whether you are in a BC or a AD era.
So, leaving aside “era”, what about having BC years shown (in the debugger) as negative numbers: year -46 as opposed to year 46? Although I guess that that too is not something possible.
BTW: this post was prompted by the fact that yesterday I lost a couple of hours over this “dilemma”. I had this bunch of years and I couldn’t understand why in the debugger I kept getting “year 46” instead of -46 (as entered in the code). Then, testing with “era” in System Prefs, solved my doubts.
Thanks.
From the LR:
A Date object stores the number of seconds since 12:00 AM, January 1, 1904, i.e., "1904-01-01 00:00:00".
And:
On Windows (due to the Windows API being used), it is not possible to go back further than 1 January 1601.
And you want to use it for BC dates ? 
@Carlo Rubini I agree that something should be added to dates BC, even if it does not follow any standard (according to WP, any year before 1583 is not standard anyway and requires mutual agreement of the partners exchanging information).
It is obviously possible to make a Date subclass “properly” reporting dates while debugging.
@Emile Schwarz
The classic “date” object, while it “stores the number of seconds since 12:00 AM January 1, 1904” has always been able to deal with ancient dates, on the Mac.
As Stephane pointed out, you then have to interact with gregorian and julian dates etc. in order to reach a certain kind of consistency in your app.
Carlo:
I am fully aware of that. I just wanted to hilight a fact.
Another one, was some answer I get while I was talking about dates fro someone in this forum, years ago. the note was something like: Use the date for the current century (or so); it is not done to deal with history.
This enforce what was said to me, years ago: the Date Class is misnamed: this is not created to deal with date from the Earth history.
Other languages that have DateTime objects have another object called Calendar to handle different “cultures of time” and eras.