Entering strange birth data

[Jody Thomson 0]

Now that I've returned from the conference/cruise where I learned soooo much, I have begun - with great enthusiasm - to enter all my sources/citations for the data transferred from another now defunct program. But I have a problem :

 

When I enter a Rhode Island birth date as it was recorded in the original document as "23 (9) 1643" TMG does not prompt me with a 'non-standard date' box and thereby let me say something to the effect of 'keep it anyway - I like it that way'. Instead, I am given dates "1643 - 1643". My way around this is to enter simply "1643" on the birth tag entry screen and then to enter in the memo on that page that his birth was recorded as "23 (9) 1643"

 

I know that I can convert this old notation into 23 Nov 1643. But I would rather not. I could easily make an error in my conversion sometime when I'm tired or in a hurry. I would like to keep the date as it was originally recorded - and then if anything, put the converted date into the memo.

 

Can anyone help? Thank you.

[Terry Reigel 0]

Apparently TMG tries to interpret this date, and concludes you mean between the 23 day of an unknown month in 1643 and the fourth month in 1643.

 

Some solutions:

 

1. Enter 23 Nov 1643 in the date field, which allows TMG to interpret it as a normal date and thus compute ages, and enter it in the Memo the way you found it. Then, edit the Sentence to use the Memo instead of the date field in narrative reports. This of course doesn't help if you prefer other styles of reports that don't use Sentences.

 

2. Enter a non-breaking space either before or after the date. You do that by holding the Alt key and typing 0160 on the number pad to the right of the main keyboard. This will cause it to be recorded as an irregular date, which means ages can't be calculated from it. It also keeps the extra space in reports, which may be objectionable.

 

3. Enter 23 Nov 1643 as the date, and add in the memo, or in the citation, a note about how it was recorded in the source.

[Michael Hannah 0]

My testing shows that this produces a date between the 23 day of an unknown month in 1643 and the ninth day of an unknown month in 1643. This unexpected behavior occurs with parens '()', braces '{}', or brackets '[]', so choosing another character will not work. Further, Terry's idea of the non-breaking space only works if it is a leading or trailing space, you get the same "between" behavior if it is an interior space.

 

Another option you might consider would be to enclose the date in quotes (e.g. "23 (9) 1643") which will be recognized as an irregular date. However, just as with Terry's non-breaking space, this will cause the quotes to print for this date in all reports. Yet, you might find this more acceptable as a clear indicator that this is "as recorded".

 

Hope this gives you ideas,

Edited December 22, 2006 by mjh

[Pierce.Reid 0]

This problem with the irregular date would not occur if TMG used a method similar to UFT: allow you to specify a free-format date to be whatever you want displayed, but also specify a structured date that could be used for calculations or when a report has limited space for only a standard date. An additional sort date may also be specified.

 

However, TMG currently uses one field for either an irregular date (used only for display) or for the standard date, as well as a separate Sort dqte. With an irregular date, calculations cannot be done and nothing is displayed if you want, for example, just the year. And I do not see any interest in adding this enhancement.

 

Pierce

[johnbrobb 0]

This problem with the irregular date would not occur if TMG used a method similar to UFT: allow you to specify a free-format date to be whatever you want displayed, but also specify a structured date that could be used for calculations or when a report has limited space for only a standard date. An additional sort date may also be specified.

 

However, TMG currently uses one field for either an irregular date (used only for display) or for the standard date, as well as a separate Sort dqte. With an irregular date, calculations cannot be done and nothing is displayed if you want, for example, just the year. And I do not see any interest in adding this enhancement.

 

Pierce

 

Well I am interested in such an "enhancement", except that I would call it "correcting a design flaw". A truly sophisticated program would allow the user to specify his own date format, using, say, Backus-Naur tokenization, e.g. "23 (9) 1643" could be specified as a custom template (available at data-entry time from a right-click pulldown menu) by

 

"<dd>_(<m>)_<yyyy>"

 

where

the symbol-strings in angle brackets represent standrd date parts (in this case all numeric date parts)

"(" and ")" are literal text characters

(they could be any characters except:)

"_" which is reserved to represent the standard Space character

 

Then the date could be entered (and if desired, displayed) in its native format, but also processed internally like any other date. As a programmer and software designer of 30+ years experience, I can tell you that it wouldn't be that hard to implement such a feature, and it would, in one fell swoop, address a lot of related problems with custom field formatting, not just with dates.

 

For example, the reason I am here is that I am looking for a way to accomplish TMG's stated desiderata of preventing dates from breaking at line ends. The recommended way to do this is to insert [:NB:]s into dates, which seems impossibly cumbersome, and in any case can't be done in the standard date fields which is where most dates are entered. And I've only resorted to exploring non-breaking spaces as a workaround for what I really want to accomplish: specifying my dates as "<dd><Mmm><yyyy>", i.e. without "_"(space) separators.

 

I have been trying to accomplish the same thing with WordPerfect macros, by eliding space surrounding month parts ("Jan", "Feb" etc.), but this doesn't work for dates in which there is no specified day, or for the few cases where "May", for example, occurs as a regular word. Maybe I can come up with an even more extensive macro which will eliminate spaces only between, say "May" and space-separated numbers, but there is no reason the user should have to deal with this stuff. The whole point of programming is make things easy for the user by doing the programming once, in a general way, which can accomodate all reasonably conceivable user demands.

[johnbrobb 0]

Well I am interested in such an "enhancement", except that I would call it "correcting a design flaw". A truly sophisticated program would allow the user to specify his own date format, using, say, Backus-Naur tokenization, e.g. "23 (9) 1643" could be specified as a custom template (available at data-entry time from a right-click pulldown menu) by

 

"<dd>_(<m>)_<yyyy>"

 

where

the symbol-strings in angle brackets represent standrd date parts (in this case all numeric date parts)

"(" and ")" are literal text characters

(they could be any characters except:)

"_" which is reserved to represent the standard Space character

 

Then the date could be entered (and if desired, displayed) in its native format, but also processed internally like any other date. As a programmer and software designer of 30+ years experience, I can tell you that it wouldn't be that hard to implement such a feature, and it would, in one fell swoop, address a lot of related problems with custom field formatting, not just with dates.

 

For example, the reason I am here is that I am looking for a way to accomplish TMG's stated desiderata of preventing dates from breaking at line ends. The recommended way to do this is to insert [:NB:]s into dates, which seems impossibly cumbersome, and in any case can't be done in the standard date fields which is where most dates are entered. And I've only resorted to exploring non-breaking spaces as a workaround for what I really want to accomplish: specifying my dates as "<dd><Mmm><yyyy>", i.e. without "_"(space) separators.

 

I have been trying to accomplish the same thing with WordPerfect macros, by eliding space surrounding month parts ("Jan", "Feb" etc.), but this doesn't work for dates in which there is no specified day, or for the few cases where "May", for example, occurs as a regular word. Maybe I can come up with an even more extensive macro which will eliminate spaces only between, say "May" and space-separated numbers, but there is no reason the user should have to deal with this stuff. The whole point of programming is make things easy for the user by doing the programming once, in a general way, which can accomodate all reasonably conceivable user demands.

 

Just as a followup to my previous post, I would like to share what I have just learned about non-breaking space characters. I learned this by trial and error, and since there is no online Help documentation which covers what I am about to say, perhaps this may help others who are equally at sea about this.

 

I was trying to eliminate the spaces between date parts, i.e. I prefer "12Oct1934" to "12 Oct 1934". I prefer the concatenated format mostly just because it prevents dates parts from being separated by end-of-line breaks. Since TMG itself recommends this practice, and mentions non-breaking space characters, represented by the "[:NB:]" token, but without describing what this means or what its effect is, I have been playing around with it, as a possible solution to my problem (since TMG doesn't offer a custom date template to accomplish this).

 

So anyway, I began by changing the non-breaking space character on the Reports->Options->Miscellaneous screen to something visible, namely "_" (the underscore character). I tried entering "[:NB:]"s in date fields but they just produced irregular dates, which suggested to me that they might not "take" anyway, since the program was unable to recognize these as nugatory tokens. In any case this wouldn't have been a practical solution to my problem - I would have had to change thousands of dates by hand. However I pumped out my journal-style report to my wordprocessor, WordPerfect, and, lo and behold, "_" characters were now interpolated between all my interior date parts, e.g. "12_Oct_1934". Thus, I could simply delete all these underscore characters (as long as I forebore to use them in the regular course of events), but wait - TMG also interpolated these "_"s between the word prefixes to dates, e.g. "say_12_Oct_1934". What's more, it also replaced all my TMG-generated space indents with underscores, so that my paragraphs (in WordPerfect) began, eg. "____Fourscore and seven years ago...". However, since I already have a several hundred line WP macro to tweak and clean up the stuff TMG dumps out as wordprocessor text, it was a simple matter of adding a dozen or so search & replace macros to first convert the specific combos I wanted to interpolated spaces, eg. "say_12_Oct_1934" to "say 12_Oct_1934", then to delete all remaining underscores.

 

So I am once again a happy camper, though not particularly impressed by TMGs low-level design, and still less with its documentation. But these are old complaints, which I have been articulating since v1.0.