* Casting template data as a particular data-type

[Gary_G]

Situation:
A date-type user-template field has been populated with text-type data from Ancestral Sources due to the A.S. variable {SYSTEM.DATE} being transferred to the template "Access_Date" field as a text-type value. e.g. "3/21/2024"

Obstacle:
The user-template employs the date-type, Access_Date, in the following way; {%SOUR.~DT-ACCESS_DATE:COMPACT%}, which will not work correctly with a text-type value. The template field-type cannot be changed to text-type, since it is also used by users to enter dates, which must be validated per date-type rules.

Question:
Is there a way in FH7 to cast the "Access_Date" value as a date-type to ensure that the template logic always sees the intended data-type? If so, how would that be done in FH7?

[tatewise]

Gary, please confirm that Date format is a Date Phrase.
i.e. Open the Date Entry Assistant by double-clicking the Access_Date box and see the text is in the Date phrase.

There are Date fixing plugins but the ones I've tried currently don't recognise that template Date field.
Let me investigate further...

[Gary_G]

Mike;

Here is a snapshot of the data as received by the template from A.S.

As-received by template from AS.pdf

(13.9 KiB) Downloaded 13 times

Here is a snapshot of the data-type for the Access_Date field of the template, confirming that it is seen as a date-phrase.

Received data-type.pdf

(24.61 KiB) Downloaded 11 times

I appreciate your looking into the noted plug-in capabilities.

Sure would be nice if FH7 had a type-casting capability. Perhaps this is a good example in support of having the ability to import user-functions. I believe there has been a wish-list item entered on that.

[tatewise]

I have discovered why the plugins are not finding template Date fields, and that needs fixing.

Your screenshots confirm what I thought. It is not AS but FH that is converting the data.

However, I've noticed that 3/21/2024 is not a valid UK date which should be 21/3/2024.
Is that because you have your PC system date set for USA mm/dd/yyyy format?
My guess is if you adjust the PC system date format to dd/mm/yyyy then AS will work correctly.

Alternativley, in FH set Tools > Preferences > General > Preferred Short Date Format: mm/dd/yyyy

[ColeValleyGirl]

My guess is if you adjust the PC system date format to dd/mm/yyyy then AS will work correctly.

Seems a bit drastic... perhaps Gary could simply move to the UK instead

[tatewise]

I wasn't suggesting a permanent change but just to confirm my diagnosis.
The alternative is to make FH recognise USA dates.

If it cannot be resolved any other way then my Fix Date Fields plugin could be updated to fix the problem.

[Gary_G]

Mike;

My setup is showing:
Preferred Standard Date Format: dd mmm yyyy
Preferred Short Date Format: yyyy-mm-dd [set to international format for sorting by year]

Changing the "Preferred Short Date Format" to mm/dd/yyyy does not change the interpretation of the field as a date phrase. It appears that FH7 senses the AS input as text-type being submitted to a date-type field and places quotes around it. FH7 then simply assumes it is a date-phrase because of the quotes.

[Gary_G]

Helen;

I don't need to move to the UK. I'm Canadian, not American. When I went to school, we were proud of that difference and I still spell words as they really "should" be in Canada. eg. "colour"

I only changed the short date format, because I thought FH7 needed that to sort dates correctly in international format.

[tatewise]

Gary, changing the FH Preferred Short Date Format will not retrospectively change an existing Date Phrase.
It will only be effective for future AS date entries.

As I said, it is not AS sending text-type data. AS is sending an invalid date as far as FH is concerned, so FH has no option other than to save it as Date Phrase text.

You either need to do something in AS to convert the {SYSTEM.DATE} to a valid FH format, or let it become a Date Phrase and use a plugin to fix it afterwards.

[tatewise]

We need to discuss the effectiveness of using yyyy-mm-dd short date format for sorting as it may not be as effective as you would like.

[Gary_G]

Mike;

I'm OK with permanently adjusting the FH7 preferences to: Preferred Short Date Format: mm/dd/yyyy
Will that likely fix future citations from A.S.?

[tatewise]

It should allow AS {SYSTEM.DATE} values in the format mm/dd/yyyy to be entered successfully into FH Date fields.
Try it and see. They will get converted to the usual dd Mmm yyyy Compact format.

[Gary_G]

Mike;

FH7 seems to sort dates correctly without using international format, so I'm happy using UK/Canadian format [if that's the solution].

It could be a problem for US dates, which reverse the month and day. French dates will be OK as they use the UK order of dates. But; I can reverse US ones in my data-entry. I will need to standardize dates to use one format, anyway. My reports often several countries and multiple formats are not only confusing but not really possible in a practical sense.

Added...
I'm sure things will work out as I enter additional citation info. The month-day-year format can present some potential ambiguity issues due to commas within templates, but I think it's likely minimal. Personally; I am MUCH more comfortable with seeing dates like, Mar 21, 2024, despite what US-based genealogy books might promote.

Guess that doesn't solve the issue for US-based users, so I hope that the issue can be fully addressed for their sake.

[NickWalker]

I think the System Date was just something I added long ago following a request from a user, with the idea being it would be displayed in auto-text rather than being stored in a date field. I have already made changes to my development version of AS to allow formatting of the system date based on another request from Gary, but if/when those updates ever get released is a different kettle of fish as I've discussed elsewhere.

[Gary_G]

Nick;

I appreciate you chiming in. By setting the FH7 options to reflect those of the UK, things should now work for me.

As for releasing new features, I understand your constraints in that area.

My comment about fixing things was not intended as anything more than a general comment that the situation could still affect US users. It wasn't directly related to A.S., because it could also be solved by allowing data-type conversion in FH7 or even user-defined formulae.

[Gary_G]

I realized, after posting, that I'd got the date systems completely turned around. My apologies to those who I confused. I see so many Time/Date formats these days that it's difficult to keep things straight anymore.

My Mac, despite being set to "Canadian" settings was using the American Time/Date format.
Then, my Windows 11 seems to have picked that up when installing under Parallels.
Finally; FH7 and A.S. have their defaults. ie. dd mmm yyyy and dd/mm/yyyy

All-in-all a royal mess...

I've gone back and tweaked the Mac and Windows to use the same Time/Date format as the default in FH7. Unfortunately; it's not clear to me whether the FH7 defaults (dd mmm yyyy and dd/mm/yyyy) mean that the numbers should be padded with leading zeros or not. The Mac can apparently do this if selected. Can someone tell me if FH7 expects such padded dates?

[NickWalker]

I know this isn't what you asked but in the current version of AS, if you use the SYSTEM.DATE it displays the date in the default 'Short Date' format set in Windows. So if I go into the windows settings and set the region to English (United States) it displays the date in this format: 3/23/2024. If I have it set to English (United Kingdom) then the date is shown in this format: 23/03/2024. These formats can be changed in Windows settings so, for example, if you have the English (United States) region but wanted to always have short dates displayed with 2 digits for the first part of the date then that can be done.

So to summarise: when you said AS has its defaults, it is true to say that in the current release (but not future release) of AS it only allows you to show the date in the short date format. However, this will change depending on your Windows region settings.

It is interesting (to me at least) to see that if I choose English (Canada) as my region format that the default short date format is 2024-03-23 and SYSTEM.DATE uses that format in AS.

For reference, here are the Windows region date settings for UK, USA and Canada:

UK:

image.png (17.14 KiB) Viewed 427 times

USA:

image.png (17.27 KiB) Viewed 427 times

Canada:

image.png (16.59 KiB) Viewed 427 times

[Gary_G]

Nick;

Thank you for the response.

I've managed to get the Mac, Windows, FH7 and A.S. to all specify dates in the same way (in my case British). However; the use of a Mac and Windows under Parallels does complicate things a bit, because Apple (bless their hearts) seems to have set up the Canadian region as using the American date format. I "think" that Parallels picked that up during installation and set up Windows 11 that way as well. When I then loaded FH7 and A.S., it caused a bit of a disconnect that required me to set the region parameters for the Mac and Windows to a British date format and make sure that the date formats for FH7 and A.S. were using their "default" setting. Once I did that, everything worked well.

I should also note that the Mac can set up the British date format with or without padding and the full year. I tried the leading-zero padded version and the full four-digit year. That is because the FH7 configuration options seemed to indicate that the date elements had a fixed width. That worked just fine, but I didn't try to see if it was absolutely necessary.

[NickWalker]

I think the System Date was just something I added long ago following a request from a user, with the idea being it would be displayed in auto-text rather than being stored in a date field. I have already made changes to my development version of AS to allow formatting of the system date based on another request from Gary, but if/when those updates ever get released is a different kettle of fish as I've discussed elsewhere.

Just to add to my response from last week, the auto-text mechanisms in AS were designed originally for generating generic source titles and also the source text so there was never a reason to have any of the date keywords to generate dates in GEDCOM format (e.g. 23 MAR 2024) because the dates were just for display purposes. When in recent years I built in support for the FHv7 source templates I extended auto-text so it would work with source template fields too and hadn't thought about the possibility of someone using the SYSTEM.DATE in a source template date field where the format would have to be in GEDCOM format for it to be compatible. I will ensure this works correctly in the next version of AS.

[Gary_G]

I've managed to get things working for me, Nick.
So; the issue isn't insurmountable, even with the current version.
However; I'm always looking forward to the next rabbit you pull out of your hat!

Just to let you know how I'm using it, now... (No action required on your part - just for info)
I've developed a "Universal Template (Method 1)", which handles most of the run-of-the-mill citations.
It seems to interface well with A.S., but I'll know better once I've got more citations entered.

In it, the {SYSTEM.DATE} serves as a default for the Date_Accessed.
It is intended to automatically fill in a current date when I'm entering data from images I've just downloaded.
When I'm entering pre-existing data, I go into the template on A.S. and override it to reflect the date accessed.

I'm currently looking at whether I can shorten my regular titles, since templates only seem to be able to fill in the regular title and the short title doesn't seem to be accessible. I'm also trying to make sure they're unique, as one could have the same image from different providers. Because each record has a unique ID, duplicate titles don't actually overwrite pre-existing source records, but they are confusing to figure out when looking at the interface.

[tatewise]

Gary, FH is quite tolerant of date input formats and will recognise many variants.
When a month's name is included then the order of the day and month can be either way round.
Everybody and FH has a problem interpreting dates such as 3/8/2024, 3rd of Aug or 8th of Mar?
That is when FH uses the Preferred Short Date Format to determine the day & month & year order.
However, FH does not care what separator is used and whether there are leading zeros.

[Mark1834]

The glaring omission in FH date handling is the lack of built-in support for the yyyy-mm-dd ISO format, which was designed precisely to get around these ambiguities (and is the only common format that also sorts correctly as text). Check the search for previous discussions.

[tatewise]

The earlier discussions are:
FH Short Date and ISO Format (22013)
Including update date in reports (18777)
Abbreviated month name (19707)

To clarify Mark's comment, FH does support the yyyy-mm-dd ISO format via Tools > Preferences > General tab Preferred Short Date Format setting in conjunction with the ABBREV3 date qualifier.
However, it suppresses leading zeros on the mm and dd digits which disrupts the sort order.
With that setting, it prevents other numeric-only date formats from being recognised on input.

[Mark1834]

To clarify Mark's comment, FH does support the yyyy-mm-dd ISO format

I must be missing something here. You have “clarified” my statement that FH does not support ISO dates by asserting that it does, then explaining in the very next sentence why it doesn’t…

For the avoidance of doubt, FH does not support ISO yyyy-mm-dd format. Explaining a method to use yyyy-m-d (which is a different format, not ISO) to resolve date/month ambiguity (but not text-based sorting) is a good additional point to make, but your imprecise “clarification” was likely to mislead rather than clarify.