Jump to content
Sign in to follow this  
retsof

Date format for years before Christ (B.C.)

Recommended Posts

TMG does not handle years before 1 A.D. and struggles with the first century A.D. years before 101, as it wants me to "fix" the century, but finally accepts a year from 0001 through 0100.

 

There was no year zero, which messes up the continuity, but we are aware of that. 46 B.C. (year of confusion of 445 days before the Julian calendar started in 45 B.C.) introduces more fun, along with inconsistencies of setting early Julian leap years.

 

I put B.C. dates in the memo field as do most people. I did find that I can separate these from other unknown dates or no date at all by entering "b 0001" (before 0001) in the date field. That helps a little and gives these a catagory separate from later A.D. years at least.

 

I don't see any reference to what version 8 will do about this, but it's still early. The preliminary file of what it will do is still in the overview stage.

Edited by retsof

Share this post


Link to post
Share on other sites

Viewing TMG's published format of how dates are stored internally, I am guessing that changing the program to deal with BC dates as regular dates would be quite a big effort. However, I think the current (Advanced mode) feature of Sort Dates can already do what you desire. Have you noticed the "work around" proposals for BC dates that were posted on the TMG-L e-mail archives back in April, 2008? Richard Damon proposed the following which uses Sort Dates:

  • Put the actual date in the Date field but with a trailing 'BC' so that TMG will recognize it as an irregular date
  • Enter a four digit (or however many digits you need to cover your oldest year) "9's complement" of the year in the Sort date field, but again use a trailing 'BC' so that TMG will recognize it as an irregular date

Since TMG sorts irregular dates in alphanumeric order prior to all regular dates, this should put all your BC dates in the proper order. As an example:

Date	  Sort Date100 BC	  9899 BC10 BC	   9989 BC2 BC		9997 BC1 BC		9998 BC

Reports will print what is in the Date field but events will be sorted in correct order because of the Sort Date. I think this will do just what you want?

 

As you noted, for early AD dates if you always enter the year as a four digit number with leading zeros, then TMG will always recognize it as a year instead of having to guess whether it might be digits representing a day or month .

 

Hope this gives you ideas,

Share this post


Link to post
Share on other sites

I have a few nines complement dates in an imported database, but they combined it with the regular date and didn't suffix it with BC to force an irregular date (since they probably weren't using TMG). I'll try it with that addition by nines complementing the sort date as above. That should be much better and I can put circa, before or after in the date fields and the sort will still be correct. It's easy to hit the "update sort field" by mistake so I also am putting the 9s complement in the memo field. It's a bit of double work, but might serve to show what I have entered into the sort field without looking again each time. Yes, the events for a person are visible in nice descending BC date order and cross over correctly to ascending AD.

 

Never mind about the before 0001 AD category. I lost the BC association in the picklist since the memo column isn't visible.

Edited by retsof

Share this post


Link to post
Share on other sites
TMG does not handle years before 1 A.D. and struggles with the first century A.D. years before 101, as it wants me to "fix" the century, but finally accepts a year from 0001 through 0100.

 

There was no year zero, which messes up the continuity, but we are aware of that. 46 B.C. (year of confusion of 445 days before the Julian calendar started in 45 B.C.) introduces more fun, along with inconsistencies of setting early Julian leap years.

 

I put B.C. dates in the memo field as do most people. I did find that I can separate these from other unknown dates or no date at all by entering "b 0001" (before 0001) in the date field. That helps a little and gives these a catagory separate from later A.D. years at least.

 

I don't see any reference to what version 8 will do about this, but it's still early. The preliminary file of what it will do is still in the overview stage.

 

Once again, I second this wish for TMG support of BC dates. As mentioned before, several of my historian and DFA genealogist friends have rejected using TMG due to this shortcomming. Most of human recorded history occurred BC.

 

While an elegant treatment of BC is desired, something simple like negative year support would be far better than what we have. Sure, selected elapsed time calculations might be off by 1 year, but that's far better than being off by thousands.

 

Best wishes,

Share this post


Link to post
Share on other sites

Mike,

 

Re: "Most of human recorded history occurred BC."

 

I don't think that's accurate. Most of human history occured B.C., but most of it was not recorded.

Share this post


Link to post
Share on other sites
Mike,

 

Re: "Most of human recorded history occurred BC."

 

I don't think that's accurate. Most of human history occured B.C., but most of it was not recorded.

 

I rest my case, as you indicate.

 

Recorded history began beyond 3000 years BC. Only about 2009.03 years have been recorded since BC.

 

Recorded history can be measured by the length of the period covered, not just the number of written words that have, somehow, miraculously survived the ages from BC. No one can even guess at the volume of recorded history that has been lost. The library at Alexandria was but a small percentage of those ancient treasures destroyed. Never the less, much did survive.

 

Do we just differ in semantics? Or...Is it your opinion that BC dates might just as well remain unsupported by TMG?

 

I remain an avid fan of TMG. There is no harm intended in wishing that it were better.

 

Respectfully,

Share this post


Link to post
Share on other sites
...Is it your opinion that BC dates might just as well remain unsupported by TMG? ... Respectfully,
And we can, respectfully, disagree that BC dates are "unsupported" by TMG. Thanks to the TMG feature of a Sort Date, BC dates can be "made" to work. It may be a bit cumbersome on data entry, but TMG will support both a correct sort order and appropriate output in reports. I agree that if TMG handled BC dates as regular dates it would make it easier on data entry for the user, but I disagree with the term "unsupported".

 

Just one (other) user's opinion :rolleyes:

Share this post


Link to post
Share on other sites
Do we just differ in semantics? Or...Is it your opinion that BC dates might just as well remain unsupported by TMG?

I have no specific objection to extending the date format in TMG to handle BC dates. I don't think it should be a high priority, but that's a personal opinion and you are certainly entitled to yours. Based on what I know about how dates are stored and processed in TMG, recording BC dates would require a fair amount of work and that's another reason I would not make it a high priority.

 

You were right that your comment referred specifically to recorded history, and yes, some of the activity during that time was recorded and a subset of those records have been retained. My point was that using that argument to increase the priority of the request doesn't influence me, but that's just my opinion and I don't speak for Wholly Genes.

Share this post


Link to post
Share on other sites
I'm actually quite intrigued to know just who/what people are recording 'BC' in TMG

 

To mention a few examples - Roman emperors and famous persons, the Ptolomys and others of Alexander's generals, other Greek and middle eastern kingdoms and empires, the pharoahs, etc. There are several groups of "Descent From Antiquity (DFA)" fans. I don't get into it as deeply as they do, though.

 

Genealogy eventually looses its luster if you confine yourself to your family, only. The satisfaction remains, but the joys of discovery become rare.

 

Best wishes,

Edited by Mike Talbot

Share this post


Link to post
Share on other sites
I'm actually quite intrigued to know just who/what people are recording 'BC' in TMG

 

Oops, forgot to answer your primary question.

 

I know of only TMG users claiming to need BC dates in this forum.

 

There are many in the history teacher/professor, archaeologist and DFA groups who delve into BC genealogy. They don't use TMG, but might like to do so if BC dates were supported (even as crude as allowing negative years, only off by 1 when BC/AD crossovers occur).

 

The genealogy program that I used over a decade ago, allowed negative years. But it had many fatal flaws, like limiting a dataset to 32767 people.

 

BTW- usage of bizarre work-arounds, like nines complement years, fall apart for those born BC, then had events AD, like death, etc. Happens often.

 

Best wishes,

Share this post


Link to post
Share on other sites
BTW- usage of bizarre work-arounds, like nines complement years, fall apart for those born BC, then had events AD, like death, etc. Happens often.

 

Best wishes,

It does? It seems to do exactly what I want.

 

Here's Antonia the Younger of the Roman Empire. 9s complement of the sort date sets the timeline in the correct order in TMG 7 for me.

 

sort | date

9963 BC circa 0036 BC birth of Antonia

9984 BC 0015 BC son Germanicus Julius Caesar born

9986 BC 0013 BC dau Julia Livilla 'the elder' born

9989 BC 0010 BC son Claudius I Emperor of Roman Empire born

circa 0037 circa 0037 (AD) death of Antonia

 

adding "BC" in the sort date seems to be optional. It will work either way for some distance BC.

There must be some year in the future that is the high end for TMG.

After a quick test, I'll call it 3000 A.D.

3001 is recorded as an irregular date.

 

Here's something else though. Birth and death dates seem to be moving around to their correct spot but dates as recorded in notes do not. Something is different.

 

I may repeat a few trials and report later. The database seems to have a mind of its own today and even the above example is being resistant to change. I'll optimize / validate file integrity / optimize and do it again. I had imported a few records and had optimized but not a VFI today.

 

That might have fixed it. A note for 100 BC and complement 9899 BC moves to before the others.

 

p.s.

 

Ashleigh Brilliant did wonder whether the folks in the Dark Ages had problems dealing with the Y1K crisis, when AD years went from 2 to 3 digits.

 

http://www.ashleighbrilliant.com/writings.html#Y1K%20CrisisS

Edited by retsof

Share this post


Link to post
Share on other sites

As the person who was quoted as proposing this let me add a few things.

 

BC and AD dates work fine together as long as the AD sort date is regular, as all regular dates come after irregular dates. The years 1 AD to 31 AD cause a bit of a problem as these tend to become irregular as TMG doesn't know if this is a year or a day of the month. To fix these I can use an irregular date of 9999yy AD where yy is the AD year. If you have a different type of irregular date, then I tend to convert the sort date to something regular that approximates the right date, otherwise it falls out of order even if you don't use BC dates.

 

I would not call this method as TMG "supporting" BC dates, it makes it tolerate them reasonably well, but BC dates are still missing a lot of features like age calculation.

 

As to how hard it would be for TMG to support it better, the data base format could with a minor change support recording the data. Currently dates are stored in a field that begins with a regular/irregular flag, followed by (for regular dates) the Year, month, and day in numeric format. Regular dates have the flag being a 1, irregular dates have the flag being a zero and the irregular date following.

 

Thus we get the following records and the dates they represent: (I am ignoring the rest of the field for now, that encoded other aspects of the date like circa, say, or between)

 

09899 BC 100 BC

101000000 100 AD (month and day = 0 means unspecified)

 

All that would need to change would be to change this 0/1 flag be a 0/1/2 flag, 0 being irregular, 1 being BC, 2 being AD, with TMG doing the 9's complement on the year automatically.

Share this post


Link to post
Share on other sites

Hi Richard,

 

First, I agree, and so did John, that your request for TMG to handle BC dates is reasonable, but I suspect that Wholly Genes will probably base this priority on their perception of the likely number of users who would need/want this feature. So posts like yours and Mike's may influence that perception. I don't personally have a need for this, but can understand its value to you.

 

BC and AD dates work fine together as long as the AD sort date is regular, as all regular dates come after irregular dates.
Correct, as that is what makes the 9's-complement "work around" proposals for BC dates that were posted on the TMG-L e-mail archives work.

 

The years 1 AD to 31 AD cause a bit of a problem as these tend to become irregular as TMG doesn't know if this is a year or a day of the month.
As I mentioned and you noted, for early AD dates if you always enter the year as a four digit number with leading zeros, then TMG will always recognize it as a year and a regular date. When your data entry is ambiguous, you cannot expect the software to always "guess" correctly.

 

I would not call this method as TMG "supporting" BC dates, it makes it tolerate them reasonably well, but BC dates are still missing a lot of features like age calculation.
Okay, I take your point. However I think it simply reflects a typical attitude among software developers that they make the common thing easy with full functionality, yet tolerate/allow/support/provide some way to accomodate the less common but with perhaps somewhat less than full functionality.

 

As to how hard it would be for TMG to support it better, the data base format could ... [snip]
If Wholly Genes decides to implement this feature I suspect they will consider this as one possible format, but there may be other issues that encourage them to use a different format. Since I am just a user like yourself, and have not examined the code, I don't know what would be easy or hard. An easy data base format is not the same as easy coding. Since John has quite a bit of experience with coding his Utility and Second Site, I tend to bow to his opinion on that.

 

Again, it never hurts to post your wishes here in the Forum. History has shown that Wholly Genes often adds features based on wishes like this. And the more users who express their desire for a feature the more likely it seems that Wholly Genes will implement it some time in the future.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×