Date   
Re: Rearranging puctures

J. P. Gilliver (John)
 

On Thu, 23 Jul 2020 at 20:01:11, Pat Brown <mistyhaven@...> wrote:
Thanks John. As a workaround I would link a photo showing both husband
and wife to each separately and list it as individual. 
[]
Yes, that should work for most cases; if both links are to the same image file, then changes (such as getting a better copy of the image) will appear in both people's strip. It's only notes you have to then remember to change in both places (and I rarely use BK image notes - I use notes in the image file itself [I then C in IrfanView; other image handlers are available]), oh and also the sources become separate when you do this.

There are also similar problems with which image you designate "Primary", when you have an individual one for one member of a couple and only a couple one for the other: this can also be got round by making two "individual" links to the same image file. (Just remember that N and S need changing in two places from then on.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

By most scientific estimates sustained, useful fusion is ten years in
the future - and will be ten years in the future for the next fifty
years or more. - "Hamadryad", ~2016-4-4

Re: Rearranging puctures

Pat Brown
 

Thanks John. As a workaround I would link a photo showing both husband and wife to each separately and list it as individual. 


On Thu, Jul 23, 2020, 19:03 John Steed <brothers_keeper@...> wrote:
To Pat Brown

There is a column that says Individual or Family

The Family pictures must be below the Individual pictures

There is a technical reason for that.

John Steed


From: BrothersKeeperGenealogy@groups.io <BrothersKeeperGenealogy@groups.io> on behalf of Pat Brown <mistyhaven@...>
Sent: Wednesday, July 22, 2020 9:34 PM
To: Brother's Keeper <BrothersKeeperGenealogy@groups.io>
Subject: [BrothersKeeperGenealogy] Rearranging puctures
 
Hi,
    For some reason where I have added a number of pictures to a person and I rearrange them by moving up or down the minute I leave that person the order reverts back to the original order. Am I doing something wrong?

Paddy 

Re: Rearranging puctures

John Steed
 

To Pat Brown

There is a column that says Individual or Family

The Family pictures must be below the Individual pictures

There is a technical reason for that.

John Steed


From: BrothersKeeperGenealogy@groups.io <BrothersKeeperGenealogy@groups.io> on behalf of Pat Brown <mistyhaven@...>
Sent: Wednesday, July 22, 2020 9:34 PM
To: Brother's Keeper <BrothersKeeperGenealogy@groups.io>
Subject: [BrothersKeeperGenealogy] Rearranging puctures
 
Hi,
    For some reason where I have added a number of pictures to a person and I rearrange them by moving up or down the minute I leave that person the order reverts back to the original order. Am I doing something wrong?

Paddy 

Re: Rearranging puctures

Pat Brown
 

Thanks J.P. Do you know if this is under consideration for a future edition? 


On Thu, Jul 23, 2020, 06:51 J. P. Gilliver (John) <G6JPG@...> wrote:
On Wed, 22 Jul 2020 at 23:40:39, Pat Brown <mistyhaven@...> wrote:
>OK, just figured it out. It will always place FAMILY photos after
>INDIVIDUAL photos. Any way to change this? 
[]
Not in the current versions; couple (or "family") pictures (and, I
think, media) are always listed after individual ones. The only thing
you can change is whether they're called couple or family, but that
won't change the order.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Just seen a Dyslexic Yorkshireman wearing a cat flap!



Re: Rearranging puctures

J. P. Gilliver (John)
 

On Wed, 22 Jul 2020 at 23:40:39, Pat Brown <mistyhaven@...> wrote:
OK, just figured it out. It will always place FAMILY photos after
INDIVIDUAL photos. Any way to change this? 
[]
Not in the current versions; couple (or "family") pictures (and, I think, media) are always listed after individual ones. The only thing you can change is whether they're called couple or family, but that won't change the order.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Just seen a Dyslexic Yorkshireman wearing a cat flap!

Re: Rearranging puctures

Pat Brown
 

OK, just figured it out. It will always place FAMILY photos after INDIVIDUAL photos. Any way to change this? 


On Wed, Jul 22, 2020, 23:34 Pat Brown via groups.io <mistyhaven=gmail.com@groups.io> wrote:
Hi,
    For some reason where I have added a number of pictures to a person and I rearrange them by moving up or down the minute I leave that person the order reverts back to the original order. Am I doing something wrong?

Paddy 

Rearranging puctures

Pat Brown
 

Hi,
    For some reason where I have added a number of pictures to a person and I rearrange them by moving up or down the minute I leave that person the order reverts back to the original order. Am I doing something wrong?

Paddy 

Re: year quarters (was: Re: [BrothersKeeperGenealogy] detecting invalid dates, and date ramblings in general)

Nick Higton
 

Even before the current pandemic, there was occasionally a long wait for a cremation. One of my relatives died three days before Christmas, and it was the end of January before a cremation slot was available. I think the Registrar also had a long Christmas/New Year closure, thus delaying issue of the Death Certificate.
Re death certificates, I should also have added that a certificate will only be issued by the Registrar upon receipt of a cause of death form (this may not be exactly the correct terminology) from a medical practioner.  This can be the family doctor, or hospital doctor, if the death is of natural causes, but must be from a Coroner if unnatural.
I suppose this would stop, for example, someone allegedly being murdered by poisoning, and the evidence going up in smoke before an autopsy could be performed.

Re: year quarters (was: Re: [BrothersKeeperGenealogy] detecting invalid dates, and date ramblings in general)

J. P. Gilliver (John)
 

On Tue, 21 Jul 2020 at 18:42:48, Andrea P K Hay via groups.io <hay438=btinternet.com@groups.io> wrote:
@font-face{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}
(I think this is a plain-text newsgroup, so probably worth setting your newsreader to plain text.)

I like that Q1 1954 (in my case) and will use this in future. Just to
add regarding burials, where I am in Hampshire people can wait 2 weeks
and occasionally longer to be buried. My husband is from Glasgow and it
is practice up there to be buried quite quickly, certainly within the
week.
For decay reasons, in the past - especially in summer - it was generally three days or less. Nowadays, with lower death rates and refrigeration, the system has less throughput capacity, and even normally there can be delays getting a slot; with the present unpleasantness, things were worse, though overall death rates are now back below normal, so that effect should be mostly passed.

Best wishes to all.

Andrea
(More ...)

On 21 July 2020, at 18:29, Nick Higton <nick@...> wrote:

I'm pleased this topic is generating discussion, and would only
reiterate that life is short (and becoming proportionately shorter by
the day for some of us), so I'm all for simplicity, and I haven't seen
anything simpler than Q1 1950 etc.
Agreed!

By the way, my understanding of the relationship between an event and
its registration in the UK is:
Births: a grace period of some weeks is allowed for registration. I
believe it is currently 42 days without penalty, so there is roughly a
50% chance that the birth registration is for a birth that occurred in
the previous quarter.
In practice I think it's a lot less than 50%, as although six weeks is _allowed_, most people do register a lot sooner (under two weeks I think). With a somewhat greater delay around Christmas, when - especially in the last 50 years or so - the offices were/are open rather less around then. (Which of course also increases the chance of the _year_ of birth being not the one when registered.)

Marriages: always registered on the day of the marriage (actually a key
part of the ceremony itself)
Certainly part of the tradition; I don't know if there is a legal obligation, though. There are probably other legal reasons to minimise delay anyway, to do with name changes, property and other rights, and so on, that don't apply for births and deaths.

Deaths: a burial/cremation cannot take place without a Death
Certificate, so the registration would typically be within a few days
of the death. In the days before refrigeration, there was some haste to
bury the body, most often by the third day after the death, hence the
death could be assumed to be only a day or two prior to the
registration
Though we still have the irritating two-part aspect to the procedure: when my mother died in hospital (St. Thomas's in London) in 200x, I still had to physically take some piece of paper down to the local registry office (in Lambeth IIRR) to actually register the death. I was most unimpressed that a large hospital couldn't do it. (I was just irritated; some are I'm sure distressed.)
[]
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"Bother," said Pooh, as he tasted the bacon in his sandwich.

Re: year quarters (was: Re: [BrothersKeeperGenealogy] detecting invalid dates, and date ramblings in general)

J. P. Gilliver (John)
 

On Tue, 21 Jul 2020 at 15:45:53, Barry P. <@Barry_P> wrote:
One good method that complies with GEDCOM standard is Bef 01-06-1894 is
indication the end quarter.
Anything that makes special use of a particular date comes a cropper when that date actually comes up, though.

EVENT NOTES will take care of the detail
Alternatively the Range 01-mmm-YYYY to 30/31-mmm-YYYY where that represents
the Quarterly period. Again Notes can elucidate on the EVENT detail.
This method is also consistent with GEDCOM, so BK needs no changes.
True, but as Nick Higton says, life is short - entering two dates to make a range is significantly tedious in BK (and probably other softwares).

See here the two options in BK for Gedcom to indicate periods.
1 DEAT
2 DATE BET 01 JAN 1909 AND 31 MAR 1909
2 PLAC Test Died
1 BURI
2 DATE FROM 01 JAN 1909 TO 31 MAR 1909
2 PLAC Test Burial

Legacy for instance can use the style above, along with mm Q YYYY
Is "mm" there two digits? Do they signify a month? If so, does it know that 01 Q, 02 Q, and 03 Q are all the same quarter? (I was going to say "or two letters", but that wouldn't differentiate between March and May, or June and July.)

Legacy has an option to not convert Quarters to date range on Gedcom
export.
And a Legacy export as mmm Q YYY but Validator reports "not valid Date".
Because of the three-digit year, or the three-character month?

Barry P.
Christchurch, New Zealand.
--==--
[]
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

... a series about a grumpy old man who lives in a phone box is unlikely to
have been commissioned these days. 798 episodes later ...

disregard rwmarriott at rochester dot rr dot com

Roy Marriott <rwmarriott@...>
 

BK Listers.
Please do not click on any links from this email address.
It's been hacked and spoofed and I will be unsubscribing this address right after this.
I'm sorry for all the trouble.
Roy

Re: year quarters (was: Re: [BrothersKeeperGenealogy] detecting invalid dates, and date ramblings in general)

Andrea P K Hay
 

I like that Q1 1954 (in my case) and will use this in future. Just to add regarding burials, where I am in Hampshire people can wait 2 weeks and occasionally longer to be buried. My husband is from Glasgow and it is practice up there to be buried quite quickly, certainly within the week.

Best wishes to all.

Andrea



On 21 July 2020, at 18:29, Nick Higton <nick@...> wrote:


I'm pleased this topic is generating discussion, and would only reiterate that life is short (and becoming proportionately shorter by the day for some of us), so I'm all for simplicity, and I haven't seen anything simpler than Q1 1950 etc.
By the way, my understanding of the relationship between an event and its registration in the UK is:
Births: a grace period of some weeks is allowed for registration. I believe it is currently 42 days without penalty, so there is roughly a 50% chance that the birth registration is for a birth that occurred in the previous quarter.
Marriages: always registered on the day of the marriage (actually a key part of the ceremony itself)
Deaths: a burial/cremation cannot take place without a Death Certificate, so the registration would typically be within a few days of the death. In the days before refrigeration, there was some haste to bury the body, most often by the third day after the death, hence the death could be assumed to be only a day or two prior to the registration

Re: year quarters (was: Re: [BrothersKeeperGenealogy] detecting invalid dates, and date ramblings in general)

Nick Higton
 

I'm pleased this topic is generating discussion, and would only reiterate that life is short (and becoming proportionately shorter by the day for some of us), so I'm all for simplicity, and I haven't seen anything simpler than Q1 1950 etc.
By the way, my understanding of the relationship between an event and its registration in the UK is:
Births: a grace period of some weeks is allowed for registration. I believe it is currently 42 days without penalty, so there is roughly a 50% chance that the birth registration is for a birth that occurred in the previous quarter.
Marriages: always registered on the day of the marriage (actually a key part of the ceremony itself)
Deaths: a burial/cremation cannot take place without a Death Certificate, so the registration would typically be within a few days of the death. In the days before refrigeration, there was some haste to bury the body, most often by the third day after the death, hence the death could be assumed to be only a day or two prior to the registration

Re: year quarters (was: Re: [BrothersKeeperGenealogy] detecting invalid dates, and date ramblings in general)

Barry P.
 

One good method that complies with GEDCOM standard is Bef 01-06-1894 is
indication the end quarter. EVENT NOTES will take care of the detail
Alternatively the Range 01-mmm-YYYY to 30/31-mmm-YYYY where that represents
the Quarterly period. Again Notes can elucidate on the EVENT detail.
This method is also consistent with GEDCOM, so BK needs no changes.

See here the two options in BK for Gedcom to indicate periods.
1 DEAT
2 DATE BET 01 JAN 1909 AND 31 MAR 1909
2 PLAC Test Died
1 BURI
2 DATE FROM 01 JAN 1909 TO 31 MAR 1909
2 PLAC Test Burial

Legacy for instance can use the style above, along with mm Q YYYY
Legacy has an option to not convert Quarters to date range on Gedcom
export.
And a Legacy export as mmm Q YYY but Validator reports "not valid Date".

Barry P.
Christchurch, New Zealand.
--==--

-----Original Message-----
From: BrothersKeeperGenealogy@groups.io
[mailto:BrothersKeeperGenealogy@groups.io] On Behalf Of Andrew Jackett
Sent: Tuesday, 21 July 2020 8:02 AM
To: BrothersKeeperGenealogy@groups.io
Subject: Re: year quarters (was: Re: [BrothersKeeperGenealogy] detecting
invalid dates, and date ramblings in general)

To J.P. Gilliver and all,

I understand that quarters are still used in compiling BDM records in New
Zealand although the event date in days, months, years is the most common
reference point for their historical records. I would imagine that other
countries would follow a similar referencing system to the UK and New
Zealand.

The British system seems to use quarters for death records only up to about
1959 when deaths got so numerous that they went to a monthly system but
still the month of registration didn't always necessarily agree with the
calendar month of the death so there's a slight anomaly there with that too.

Furthermore the system used to signify quarters of the year is not observed
unanimously by all. Q1 1920 is a common one, but another format is (1) 1920
through (4) 1920 and still another is Mar Q 1920, Jun Q 1920, Sep Q 1920 and
Dec Q 1920.

The quarter dates don't match exactly the calendar dates at times so it is
useful to define which is being referenced in dates as has been mentioned.

I am keen for John Steed to work quarter dates into the code so they have
better functionality some time too.

I quizzed the MyHeritage Support guys today and they said their software
doesn't make use of quarters functionality either but Legacy software seem
to have adopted the material early on even if GEDCOM files don't officially
work with it.

An interesting topic. I hope more good material comes out of it soon.

Andrew Jackett of New Zealand


-----Original Message-----
From: J. P. Gilliver (John)
Sent: 21 July, 2020 5:35 AM
To: BrothersKeeperGenealogy@groups.io
Subject: year quarters (was: Re: [BrothersKeeperGenealogy] detecting invalid
dates, and date ramblings in general)

On Mon, 20 Jul 2020 at 00:35:57, Nick Higton <nick@...> wrote:
Where a date is recorded in the original document (e.g. the British
General Record Office Birth, Marriage & Death Indexes) as a quarter of
the year, I've come across others who record it as, for example, __ Jan
1910, or __ Mar 1920. This, in itself, is confusing, as the date might
be taken as confirming the event as within the stated month, and not
the quarter.
Exactly my view.

Further, the GRO date is the date of registration of the event, not
of the event itself, and the birth registration can be up to six weeks
after the birth.
Also true, though I could live with it (if I _knew_ it was from a GRO index,
I'd be aware of that. [I think the permitted period has varied over time -
plus there are the cases where the permitted delay has been exceeded and a
fine paid; I don't know if the GRO then back-amend,
though.])

For these reasons, I've always recorded the date as Q1 1930 etc., and
Me too, with the Qx in the comment field ...

have found that BK will accept the year as vaiild for working out ages,
but it ignores the quarter.
... but I didn't know that! I'd jut assumed that anything non-standard would
be treated as free-form, and thus not calculated on. Thanks!

I realise that my approach is shorthand, and might well be
misinterpreted by others. The accurate way to record the event would
to have a "Birth Registration" Event, and to then record the date as
between 01 Jan 1940 - 31 Mar 1940 but, frankly, life's too short.
Yes, I've thought that too. Both thoughts - that it should be shown with a
start [which should arguably really be 1_ Nov 1939 for your example!], and
that life's too short.

Would it be possible for BK recognise such dates directly (and accept
that it will not be GEDCOM compliant)?
[]
Yes please ... (-:

Are there other jurisdictions - some states of the USA for example? - who
use quarters?
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Heaven forbid today's audience should feel bombarded with information or
worse, lectured. Dont'scare the horses by waving facts around.
- David Butcher, RT 2014/11/29-12/5

Re: year quarters (was: Re: [BrothersKeeperGenealogy] detecting invalid dates, and date ramblings in general)

J. P. Gilliver (John)
 

On Tue, 21 Jul 2020 at 08:01:52, Andrew Jackett <ajackett@...> wrote:
To J.P. Gilliver and all,
(John)
[]
The British system seems to use quarters for death records only up to about 1959 when deaths got so numerous that they went to a monthly system but still the month of registration didn't always necessarily agree with the calendar month of the death so there's a slight anomaly there with that too.
I know some of our indices experimented with varying intervals in the later 20th century (I think I've seen half or even whole years). Yes, we're allowed a period (another poster has said it's six weeks) to register some events. (I'm not sure if it applies to marriages; they usually seem to be registered as part of, or at least the same day as, the ceremony [it often takes place in a registry office anyway], but it's an interesting question whether they have to be!)

Furthermore the system used to signify quarters of the year is not observed unanimously by all. Q1 1920 is a common one, but another format is (1) 1920 through (4) 1920 and still another is Mar Q 1920, Jun Q 1920, Sep Q 1920 and Dec Q 1920.
As long as the Q remains, I'm reasonably happy - I don't like the ones that just use a number as that could be misunderstood as a month. (I'm not _too_ keen on "month-name Q" either, as the Q can get lost.)

The quarter dates don't match exactly the calendar dates at times so it is useful to define which is being referenced in dates as has been mentioned.
I think any reasonably-experienced genealogist fairly soon learns that, if a quarter is mentioned, that it covers a span of over three months. In fact, if I come across an event (at least a UK one after mid-1837) where only the month is given (no day), I strongly suspect that it's actually a quarter anyway (and have usually been proved right).

I am keen for John Steed to work quarter dates into the code so they have better functionality some time too.
I'm glad I'm not the only one who'd like that! Though another poster has said that - although it's not mentioned in the manual anywhere - BK _does_ recognise the year in e. g. "Q1 1950" for age-calculating purposes.

I quizzed the MyHeritage Support guys today and they said their software doesn't make use of quarters functionality either but Legacy software seem to have adopted the material early on even if GEDCOM files don't officially work with it.

An interesting topic. I hope more good material comes out of it soon.
Indeed!

Andrew Jackett of New Zealand


-----Original Message----- From: J. P. Gilliver (John)
Sent: 21 July, 2020 5:35 AM
(Must be your time - it's only 0:24 on the 21st here now!)
[]
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

The motto of the Royal Society is: 'Take nobody's word for it'. Scepticism has
value. - Brian Cox, RT 2015/3/14-20

Re: year quarters (was: Re: [BrothersKeeperGenealogy] detecting invalid dates, and date ramblings in general)

Andrew Jackett
 

To J.P. Gilliver and all,

I understand that quarters are still used in compiling BDM records in New Zealand although the event date in days, months, years is the most common reference point for their historical records. I would imagine that other countries would follow a similar referencing system to the UK and New Zealand.

The British system seems to use quarters for death records only up to about 1959 when deaths got so numerous that they went to a monthly system but still the month of registration didn't always necessarily agree with the calendar month of the death so there's a slight anomaly there with that too.

Furthermore the system used to signify quarters of the year is not observed unanimously by all. Q1 1920 is a common one, but another format is (1) 1920 through (4) 1920 and still another is Mar Q 1920, Jun Q 1920, Sep Q 1920 and Dec Q 1920.

The quarter dates don't match exactly the calendar dates at times so it is useful to define which is being referenced in dates as has been mentioned.

I am keen for John Steed to work quarter dates into the code so they have better functionality some time too.

I quizzed the MyHeritage Support guys today and they said their software doesn't make use of quarters functionality either but Legacy software seem to have adopted the material early on even if GEDCOM files don't officially work with it.

An interesting topic. I hope more good material comes out of it soon.

Andrew Jackett of New Zealand

-----Original Message-----
From: J. P. Gilliver (John)
Sent: 21 July, 2020 5:35 AM
To: BrothersKeeperGenealogy@groups.io
Subject: year quarters (was: Re: [BrothersKeeperGenealogy] detecting invalid dates, and date ramblings in general)

On Mon, 20 Jul 2020 at 00:35:57, Nick Higton <nick@...> wrote:
Where a date is recorded in the original document (e.g. the British
General Record Office Birth, Marriage & Death Indexes) as a quarter of
the year, I've come across others who record it as, for example, __ Jan
1910, or __ Mar 1920. This, in itself, is confusing, as the date might
be taken as confirming the event as within the stated month, and not
the quarter.
Exactly my view.

Further, the GRO date is the date of registration of the
event, not of the event itself, and the birth registration can be up to
six weeks after the birth.
Also true, though I could live with it (if I _knew_ it was from a GRO
index, I'd be aware of that. [I think the permitted period has varied
over time - plus there are the cases where the permitted delay has been
exceeded and a fine paid; I don't know if the GRO then back-amend,
though.])

For these reasons, I've always recorded the date as Q1 1930 etc., and
Me too, with the Qx in the comment field ...

have found that BK will accept the year as vaiild for working out ages,
but it ignores the quarter.
... but I didn't know that! I'd jut assumed that anything non-standard
would be treated as free-form, and thus not calculated on. Thanks!

I realise that my approach is shorthand,
and might well be misinterpreted by others. The accurate way to record
the event would to have a "Birth Registration" Event, and to then
record the date as between 01 Jan 1940 - 31 Mar 1940 but, frankly,
life's too short.
Yes, I've thought that too. Both thoughts - that it should be shown with
a start [which should arguably really be 1_ Nov 1939 for your example!],
and that life's too short.

Would it be possible for BK recognise such dates
directly (and accept that it will not be GEDCOM compliant)?
[]
Yes please ... (-:

Are there other jurisdictions - some states of the USA for example? -
who use quarters?
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Heaven forbid today's audience should feel bombarded with information or
worse, lectured. Dont'scare the horses by waving facts around.
- David Butcher, RT 2014/11/29-12/5

year quarters (was: Re: [BrothersKeeperGenealogy] detecting invalid dates, and date ramblings in general)

J. P. Gilliver (John)
 

On Mon, 20 Jul 2020 at 00:35:57, Nick Higton <nick@...> wrote:
Where a date is recorded in the original document (e.g. the British
General Record Office Birth, Marriage & Death Indexes) as a quarter of
the year, I've come across others who record it as, for example, __ Jan
1910, or __ Mar 1920. This, in itself, is confusing, as the date might
be taken as confirming the event as within the stated month, and not
the quarter.
Exactly my view.

  Further, the GRO date is the date of registration of the
event, not of the event itself, and the birth registration can be up to
six weeks after the birth.
Also true, though I could live with it (if I _knew_ it was from a GRO index, I'd be aware of that. [I think the permitted period has varied over time - plus there are the cases where the permitted delay has been exceeded and a fine paid; I don't know if the GRO then back-amend, though.])

For these reasons, I've always recorded the date as Q1 1930 etc., and
Me too, with the Qx in the comment field ...

have found that BK will accept the year as vaiild for working out ages,
but it ignores the quarter.
... but I didn't know that! I'd jut assumed that anything non-standard would be treated as free-form, and thus not calculated on. Thanks!

I realise that my approach is shorthand,
and might well be misinterpreted by others.  The accurate way to record
the event would to have a "Birth Registration" Event, and to then
record the date as between 01 Jan 1940 - 31 Mar 1940 but, frankly,
life's too short.
Yes, I've thought that too. Both thoughts - that it should be shown with a start [which should arguably really be 1_ Nov 1939 for your example!], and that life's too short.

Would it be possible for BK recognise such dates
directly (and accept that it will not be GEDCOM compliant)?
[]
Yes please ... (-:

Are there other jurisdictions - some states of the USA for example? - who use quarters?
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Heaven forbid today's audience should feel bombarded with information or
worse, lectured. Dont'scare the horses by waving facts around.
- David Butcher, RT 2014/11/29-12/5

Re: detecting invalid dates, and date ramblings in general

Nick Higton
 

Where a date is recorded in the original document (e.g. the British General Record Office Birth, Marriage & Death Indexes) as a quarter of the year, I've come across others who record it as, for example, __ Jan 1910, or __ Mar 1920. This, in itself, is confusing, as the date might be taken as confirming the event as within the stated month, and not the quarter.  Further, the GRO date is the date of registration of the event, not of the event itself, and the birth registration can be up to six weeks after the birth.
For these reasons, I've always recorded the date as Q1 1930 etc., and have found that BK will accept the year as vaiild for working out ages, but it ignores the quarter. I realise that my approach is shorthand, and might well be misinterpreted by others.  The accurate way to record the event would to have a "Birth Registration" Event, and to then record the date as between 01 Jan 1940 - 31 Mar 1940 but, frankly, life's too short. Would it be possible for BK recognise such dates directly (and accept that it will not be GEDCOM compliant)?

Re: detecting invalid dates, and date ramblings in general

J. P. Gilliver (John)
 

On Mon, 20 Jul 2020 at 09:06:53, Barry P. <@Barry_P> wrote:
John G.
I would suggest two methods:-
(1).- Make a list of BK#, B-Date, M-Date, D-Date, whatever- Date.
Saved as CSV / text ( save paper)
(2).- Export as Gedcom.
Copy Gedcom to either MS-Word or MS-XL
In XL you can use a formula to bring out the dates
Ingenious; I hadn't thought of using Excel. (Still seems an awful lot of effort to find non-standard ones though!)

In any Case You can sort (Assuming you have a sequence column for the rows
of data fields..
Be able to see what form or 'shape' the dates are is a major step forward
Clever.

I had a conversion problem where many dates had different styles, so
needed to have the convert routine applied separately for each style.

As for "non-standard styles", there should not be any, except for typos.
Well, as I've been using BK for decades, I'll be surprised if there aren't any typos! And I think there might be non-standard ones too - I have a faint memory of seeing something like "7pm 23 Apr 1960" somewhere
[]
Do you know the answer to my other question: do incomplete, rather than incorrect format, dates get converted by the date format routine - so for example is __ APR 1950 converted to 1950-04-__, and BEF 01 JAN 1900 to BEF 1900-01-01?
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

We must, of course, ensure that we display no bias. The bias I worry about
most is the bias against understanding. - Nick Robinson, RT 2017/4/8-14

Re: detecting invalid dates, and date ramblings in general

Barry P.
 

John G.
I would suggest two methods:-
(1).- Make a list of BK#, B-Date, M-Date, D-Date, whatever- Date.
Saved as CSV / text ( save paper)
(2).- Export as Gedcom.
Copy Gedcom to either MS-Word or MS-XL
In XL you can use a formula to bring out the dates

In any Case You can sort (Assuming you have a sequence column for the rows
of data fields..
Be able to see what form or 'shape' the dates are is a major step forward

I had a conversion problem where many dates had different styles, so
needed to have the convert routine applied separately for each style.

As for "non-standard styles", there should not be any, except for typos.

Barry P.
--==--

-----Original Message-----
From: BrothersKeeperGenealogy@groups.io
[mailto:BrothersKeeperGenealogy@groups.io] On Behalf Of J. P. Gilliver
(John)
Sent: Monday, 20 July 2020 5:35 AM
To: BrothersKeeperGenealogy@groups.io
Subject: [BrothersKeeperGenealogy] detecting invalid dates, and date
ramblings in general

I have asked this before, but not for at least a couple of years, so
wondered if anyone's got any new thoughts, and/or there's anything new in
7.5 (I _have_ RTFM).


Detecting invalid dates:

I currently use type 2 dates (display as 15 JUN 1954, enter as 15061954 or
150654 [for 19xx dates]). I'm thinking of changing to type 11 (1954-06-15);
I'm aware of the Convert Date Format routine. I have two
questions:

1. Is there an easy way to get a list of all the dates I have that are in an
invalid format, so I can patch them after running the convert routine? I
mean ones from decades back when I might not have been using the right
format, or typos like entering an O or o for a 0, or five or seven digits
rather than six or eight, and not noticing that it didn't get converted.
2. Will non-exact dates be converted - e. g. 15 ___ 1954 or __ JUN 1954 or
1_ JUN 1954 or 15 JUN 195_ (into 1954-__-15 or 1954-06-__ or 1954-06-1_ or
195_-06-15 respectively), or will they be considered invalid and left
unchanged? Ditto ones containing ABT/CIR, BEF, or AFT?


Date ramblings:

230460 gets converted into 23 APR 1960
__0_63 gets converted into __ ___ 1963 (but is the 0 remembered?)
__0163 gets converted into __ JAN 1963 (great!)
__1_63 gets converted into __ JAN 1963 (puzzling)
21__41 gets converted into 21 ___ 1941 (great!)
3_0678 gets converted into 3_ JUN 1978
0_0567 gets converted into _ MAY 1967 (a nice touch)
____63 does _not_ get converted into __ ___ 1963, though ____1963 does (it
would be handy if it did - or just 63 or 1963 without any _s)

BK (in common with most other software and many online resources) does _not_
have a way of recording [year] quarters. (I put e. g. "Q1" in the Notes
field for the event, and leave the month blank [__] in the date.
Putting in a month, when coming back to the event some time later, can be
mistaken for extra precision. I've also come across all three selections of
month to indicate quarter - the commonest is the last month, but I've
encountered both first and middle.) I'm not sure how it _could_ be indicated
- maybe Q4 (in the month field) instead of DEC or 12?

I've just learnt (R'ing TFM does have benefits!) that I can enter "dates
with dual years such as 15-MAR-1680/81". I presume this is to account for
the year, in Britain before a certain date, ending in March rather than
December, such that March 1680 would be followed immediately by April 1681.
Do I take it that (for things like calculating age), BK would take the above
date as being in the month before April 1681?
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

It's a beta orgy, not a product. - Mayayana in alt.windows7.general,
2018-3-8