* bug in version 5.0

[ghamrick]

why is new version giving me an invalid date for (11 NOV 1855) it comes back (63 NOV 011), it accepts text phrase, but I cannot even enter the date in the popup dialog because the application is reversing the year and the day of the month? What is happening, seems like a bug in application?

ID:6071

[PeterR]

I think the problem may be cased by the Short date format in the Regional and Language Options in the Windows Control Panel.  (These may have different names in Vista or Win7.)

[ghamrick]

nothing has change on my system, all I did was install new version. the year is being switched with the day by the application. 11 is being switched with 1855 , which makes it invalid. I tried to enter it in the popup dialog for the date and got the same identical results, even downloaded and re-installed application (same results INVALID DATE). I am a seasoned assembly language programmer with 28 years experience, I know how to enter date and the bug is in the software or the download. PROGRAM IS SWITCHING YEAR AND DAY OF MONTH. I will install the old version, It works. I Don't want to loose the tree of 6000 Relatives.

[ghamrick]

if I change my settings in control pannel then dates are all switched for everyone in entire gedcom. They need to fix this bug because it modifying dates like (24 MAY 1843) to (51 MAY 0024) for an individual that I only change a name on. Major corruption of the project due to application. Why is the application dependent on system configurations anyway, the data is being stored in project file and irelevant to system settings?

[nsw]

What short-date setting was in control panel when you looked at it?

What did you change it to?

And which version of Windows?

Whatever is happening here isn't normal behaviour for version 5. A lot of users have been using version 5 (Beta testing) for 6 months+ without seeing this issue. It might not seem obvious or even logical why these settings would make a difference but the more information that can be collected the more likely a solution might be found more quickly.

[ghamrick]

dosen't matter now. I reinstalled version 4, Only reason I was using Family Historian was for the dates BC and relationship to root. (MyHeritage.com) did not support BC ERA and relationships to relatives over 5000 persons. Family Historian needs seasoned programmers, not fresh out of school grads. If the system setting for short date is (YYYY/MMM/DD) or (DD/MMM/YYYY) does not matter. The data should be deciphered as (dd mmm yyyy) as typed in either field or popup dialog box. Typed date is not dependant on system to store date, it is up to the application to convert text to numbers, then store it as such, not all the hurdles for a straight forward conversion. i.e. (text '0' = 0 binary, = , etc,...) simple math, that was made complicated by uneducated non-programmers. (NOTHING TO DO WITH COMPUTER CONFIGURATIONS PERIOD). ENGLISH 101, MATH 101, PROGRAMMING 101. I've been writing code for 28 years, eat, sleep and breath in binary.

[ghamrick]

So everone has to change their system comfigurations because Family Historian decided to be non conventional in programming. I don't think so, program should be completely independant of system configurations period, period, period... You are using non conventional coding (FH5.0.0.)  SHAME SHAME SHAME!

[ghamrick]

Version of windows, short date settings before and after, is irrelevant to the application if it was tested then it should work on a system of a professional programmer as myself. I challenge my 28 years expertice against all your programmers who say my system configurations has something to do with, an unforseen programming flaw. I use Windows XP-MCE. Been up and running since 2005, no flaws in my system. I use the year first in my shortdate, it is chronological correct to sort by year first, month then day. Can't see how anyone could possibly sort centuries of data using the day of the month as the first crieria.

[Jane]

V5 added a lot of code to allow people to enter dates, in a variety of large variety of formats, what appears to have happened was that the particular combination of settings which you are using was not caught by the beta testers.

FH is not written by 'grad students', please can you post your settings so they can test your settings and correct the issue in the next release.

[nsw]

This is not a competition - I've been programming for 30 years but so what - perhaps we're both getting too old? The issue you describe is clearly not something that everyone is seeing or there would be hundreds of people complaining about it on here. As a programmer you will know that on occasions a user will have a particular setting or other unusual isssue that causes a previously undiscovered bug to show itself.

All dates in GEDCOM are stored in the same standard format so an American entering a date as 2/3/1800 or a UK resident entering a date as 3/2/1800 will both have the date recorded in the file as 3 Feb 1800. However, Family Historian needs to use the system settings to know how it should interpret that date and indeed how to display information.

Perhaps software you've produced never has a single error, in which case they can't possibly be as complex as Family Historian. But as a programmer wouldn't you want a user to report an error to you and give you a chance to fix it?

You've reported this issue on a user group forum, not an official Calico Pie outlet. Two very experienced users have tried to help by asking you some questions in the hope that it might flag up what might be causing the bug. So instead of thanking us for taking time out of our Friday evening to try to help, you just get angry about it and within an hour of asking the question you already decided to give up and not even bother trying to help!

Nick

[Edit: You posted another response while I was writing this. No need to change to yyyy-mm-dd date format to sort dates - Windows will do that for you whatever the format. However, usually dd-mm-yyyy or mm-dd-yyyy are used so I guess none of the beta testing was carried out by anyone with your date format. Hopefully this information will now allow Calico to fix the problem in the first 'patch'.]

[ghamrick]

I can see I'm getting no where but anyway.
yyyy/MM/dd is my setting for the short date. As someone, I don't know who, posted and suggested it was my system settings, irrelevant to FH5 converting the text 11 NOV 1855.
the same problem happened in the popup-dialog (I entered 11 in the day field, November from the drop-down-list, and entered 1855 in the year field. I dont know how more specific I can get if the data is placed in the specific fields for the (day)(month)(year) as labeled. I will say though when I changed my short date settings to dd/MM/yyyy, that the date entered correctly, but any other facts that I modified in any way automaticaly changed the date without my intervention. It seems as though the programmong is using the system configurations instead of converting the text to digits from the text '11 NOV 1855'. Before storing the date thae application is switching the day with the year, even with the popup-dialog-box and correct fields. A definate bug in the application if I say 1855 in the year field and application says swap the day and year for no logical reason.

[nsw]

ghamrick said:
I can see I'm getting no where but anyway. yyyy/MM/dd is my setting for the short date

But you see you are getting somewhere now, it just took a while. Now you've explained the setting you use I've been able to try it and I can confirm that this appears to be a bug in Family Historian that means that if you use the short date setting yyyy-mm-dd it doesn't handle dates correctly. I'm sure this is something that Calico will be able to fix easily. The work around appears to be to use one of the other formats or, as you've done, revert back to FH 4 until the issue is resolved.

I can see you were upset about this but it turned out that the questions that Peter and I asked were very relevant as we now know the cause of the problem which Calico will surely fix fairly quickly.

Best wishes

Nick

[ghamrick]

My very 1st statement: 'why is new version giving me an invalid date for (11 NOV 1855) it comes back (63 NOV 011), it accepts text phrase, but I cannot even enter the date in the popup dialog because the application is reversing the year and the day of the month?....'

still don't see why system date is a factor, when the program asks up front either Engish UK or English USA and neither of those matter either. USING the DIALOG BOX: If I tell the program (the exact day in the day field, the exact month in the list-box and the year in the year field), then the program had decided to do the reverse when format order was not even an issue at all, fields were labeled day/month/year overtop the field. Makes no sense what so ever it did the oposite of the label above the field. Makes no sense period why the exact data entered needs to be checked against the system. System has a drop-down list with 8 settings for the short date, hard to believe no one checked all 8 settings since they choose to use the system settings instead. And again more rethoric because I entered the date in ABBREV Format #1  [15 Dec 1989] just as it says in the help file. I used this format for all the dates before in ver 4 and see no differences in the way that I've been typing it. Even though my system settings are yyyy/MM/dd, I've always entered the date in format of 30 MAR 2012 (dd MMM yyyy) and it gave no invalid date message and was fine. And NICK I'm not old so don't compare my age or experience with yours or talk about competitions, I was just stating my experience of 28 years in assembly code which is ten times more difficult to code in that the higher level languages, just to show I was not a total iliterate user with PC's. So I say again and for the last time, the program goes outside the box (does not need to check the system settiings to convert dates). I say again it is a bug in the software, version 4 worked fine. Version 5 is corupting the dates no mater what the system short date is (yyyy/MM/dd or dd/MM/yyyy) making the program unusable until they decide to get away from the system settings and just convert the abbreviated date as entered in the fields as they are labeled).

[Jane]

The problem appears to be limited to the Windows short date format, the common dd/mm/yyyy and mm/dd/yyyy formats are correctly processed.

The problem is only with the yyyy-mm-dd format.

The work around for now is either to to change the Windows short date format to one where the year is at the end or revert to V4 until a fix can be issued.