Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Attribute date sorting revisited and date ranges explained
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
John Nairn  
View profile  
 More options Feb 22 2012, 2:32 pm
From: John Nairn <j...@geditcom.com>
Date: Wed, 22 Feb 2012 11:32:13 -0800
Local: Wed, Feb 22 2012 2:32 pm
Subject: Re: Attribute date sorting revisited and date ranges explained
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–
> 1855 looks just silly…
> 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…
> 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… just
> a thought not a request


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.