Attribute date sorting revisited and date ranges explained - GEDitCOM II Discussions

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Attribute date sorting revisited and date ranges explained
Received-SPF: neutral (google.com: 128.193.15.36 is neither permitted nor denied by best guess record for domain of j...@geditcom.com) client-ip=128.193.15.36;
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Attribute date sorting revisited and date ranges explained
From: John Nairn <j...@geditcom.com>
In-Reply-To: <06a06085-57fa-4e55-9521-c4247026a...@db5g2000vbb.googlegroups.com>
Date: Wed, 22 Feb 2012 11:32:13 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <15AE047B-B0E1-40B3-B5F4-3D435FFF0...@geditcom.com>
References: <d0ec78cc-ac01-4f5b-8374-d659fa4cd...@gi10g2000vbb.googlegroups.com> <DDC1F4DA-EA2C-4ABD-B2C1-06A1547BF...@geditcom.com> <B07C9104-4C75-40F7-A92B-CBECCD342...@verizon.net> <D152F573-36E3-4767-9C5C-FCDE233C0...@geditcom.com> <c9e0a92d-e04d-4428-a41f-7525e3898...@b18g2000vbz.googlegroups.com> <B30079E2-D13F-4292-B307-4F2D47618...@geditcom.com> <06a06085-57fa-4e55-9521-c4247026a...@db5g2000vbb.googlegroups.com>
To: geditcom-ii-discussions@googlegroups.com

That is an option, but not the simple if statement you suggest. Date =
fields are now all handled the same. To make attribute date fields =
different then event date fields, each one will have to look up their =
parent tag and compare to list of attributes vs. events. The parent is =
not always obvious depending on where the date is accessed in the code. =
It would not be horribly difficult, but a lot more coding and loss of =
elegance in date field coding. It might slow down calculations that scan =
many dates at once.

I will look at other options instead. For example, perhaps it only =
matters to sort command and can be done in that code and would not be =
needed any place else. Also distinguishing 1855 from 1855 to 1866 is =
difficult in current sort method because it is based on one number. =
Accounting for start date and end date would require addition of =
secondary sorting criteria (unless the range can be encoded into a =
single number somehow for efficiency)

On nested dates such as FROM CAL 1777 TO BET 1784 AND 1786

These cannot be entered because GEDitCOM II has adopted all GEDCOM =
options for dates, but that option is not one of them. You do however, =
have some ways to record such a date:

1. Any date can be followed by a comment in parentheses such as

     FROM 1777 TO 1786 (1777 was calculated, end date may have been =
1784)

The comment is never used in date calculations, but will be there for =
your records.

2. To do the same thing in a hidden field, you can use the custom =
GEDitCOM II option to attach a memo to the date (or any) field:

     a. Enter FROM 1777 to 1786 into the field
     b. Control click on the field and chose "Attach/Edit Memo" from the =
pop up menu
     c. Enter any line of text (such as "1777 was calculated, end date =
may have been 1784") and then type return or enter

Now when you hover the curse over that field, the comment will appear in =
a pop-up window rather then the help string for date fields. You can =
control click again to change the memo.

If you are exporting GEDCOM data to share with others using different =
software, the first option might be better. The second option exports a =
custom tag right after that date. If you want to both use memos and =
export GEDCOMs to share in other software, you can run the script =
"Export Data/Move Memos to Notes" before exporting your data and all =
memos for a record will appear in notes for the record. They will not be =
next to the actual date, but will be available for reference.

On Feb 21, 2012, at 10:38 PM, Swanfoth wrote:

> Actually you should treat all attribute dates as date periods. A
> single year just means that it started and ended within that year. And
> if there is a true period date with the same start then the single
> year comes first. No need to compute range midpoints. Entering 1855=96
> 1855 looks just silly=85
> These moves are recorded in the the source books as [page#/year] so
> months are not available and I'd hate to invent articial months just
> to get correct order when one if-statement in the code could handle it
> easily.
> Problem solved=85
> PS
> I wonder if the date expressions can be nested by using other
> expressions in either or both ends of the period dates like
> FROM CAL 1777 TO BET 1784 AND 1786
> That may bring too much complexity but could sometimes be handy=85 =
just
> a thought not a request
>=20
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
