Hi. I’m running Gramps 6.0.8 on Windows 11, and my preferred input date is in Hebrew (which I changed in the global preferrences). When Gramps displays the date it always appends the word (Hebrew) in parentheses at the end. I find it completely unnecessary, since it’s obviously a Hebrew date, since it has Hebrew months. Is there anyway to stop Gramps from doing that? (It’s not tremendously important, but it seems that there should be some way to change it.)
seems like substituting ✡ for (Hebrew) would be a space-efficient notation.
You always use Hebrew dates. OK.
The problem is you are not alone and some people can enter dates in multiple format. If you have mixed dates, it is important to know in what calendar this date is entered.
This is similar to your request to use an orthodox dialect for calendar months.
There isn’t a method for “local overriding” a string currently.
But it is being discussed for Gramps v7 in the development forum:
I thought it was clear, since the months are named differently, it’s already known which format it’s in. If you feel that while it is clear it’s not Gregorian, others might not know what it is, I agree, I was just asking for a way to change it for me. However, I see that emyoulation already responded, that such a workaround is being discussed for a future revision.
There are two things here:
- The Hebrew month names - these are just text associated with months
- The Hebrew calendar - the math and infrastructure (leap day, epoch, etc)
So, no: using Hebrew month names is not connected to knowing that a date is using the Hebrew calendar.
So, the “(Hebrew)” is needed to be able to parse the date properly in the Hebrew calendar. There are other things that can also appear in the parentheses, such as alternate first-day-of-the-year. These are called “extras” in the code.
So, @emyoulation is correct that if we implement:
then you could use another word or symbol for the extra “Hebrew”. But you would have to use that symbol for entering dates as well.
But another option would be a preference switch like “ Don’t show date extras” that if checked would not show the extra info in specific (display-only) situations. For at least some Gramps users, this would be bad/ambiguous because you wouldn’t know what date a calendar is in just by looking at the days/months/years.
For your case, it might work. But not sure if it would be worth the chaos that could be created overall though.
Thank you for the clarification. I hadn’t understood that the parentheses was needed for the code. I thought it was just informational, and could be removed without an issue. I’m still not sure however why the code required it? Since it was input as a Hebrew date, shouldn’t that be enough?
Somehow, that having to type Hebrew does not seem reasonable if @morningstar has set the Calendar on input to the Hebrew selection. (But seems to be true.) If it is still necessary to use the parenthetical Calendar notation during input, what are the benefits of setting an input calendar?
Dates are always converted internally to the following format: yyyy-mm-dd.
That is why we need to know in which calendar it was entered.
This conversion is necessary to properly compare and sort dates when we use multiple calendars.
Off topic just a little. I entered Julian dates in a record and uploaded the record to WikiTree. The dates in WT were empty. I did not investigate why, but somewhere in the process a conversion did not happen because WT does not support different dates. So beware if you do gedcom exports.
I’m sorry but I fel like we may be talking at cross purposes here. I am talking about the display, such as in People view. The number was already inputted properly. The system should already know what date system I used. Additionally, I agree with @emyoulation that since my date was set to Hebrew, the system should already know what I am trying to do, an shouldn’t need me to type (Hebrew).
Good question. Your frustration is justified: here’s precisely what’s going on.
“Calendar on input:” only affects the Date Selection dialog, not the plain text field.
The only place in the entire codebase that calendar preference is read is the setting of the default calendar in the date-entry dialog. It is used only when you click the little calendar button to open the structured Date Selection dialog on a still-empty date field — it pre-picks “Hebrew” in that dialog’s drop-down so you don’t have to switch it manually, and lets you type the year/month/day numbers directly into that dialog’s fields with no parenthetical needed at all.
It has zero connection to the plain text field you type into directly. I checked DateParser.set_date() and it hardcodes cal = Date.CAL_GREGORIAN as the starting assumption every single time, and only switches away from Gregorian if it finds a (Hebrew)-style annotation in the text itself. There’s no config lookup anywhere in that parser at all. So typing straight into the text box always assumes Gregorian first, preference setting or not.
So the real answer to “what’s the benefit”: the preference saves you exactly one dropdown click — but only if you use the calendar-picker dialog instead of typing dates as free text. If your workflow is “type the date directly into the field,” the preference does nothing for you, and yes, you still need “(Hebrew)” every time. If instead you get in the habit of clicking the date-editor button and entering year/month/day in its structured fields, the preference does what you’d expect and you never need to type the annotation at all.
That’s a genuine inconsistency in the UX: it is reasonable to expect the preference to also change the plain-text field’s default parsing calendar, and it doesn’t. Worth making a second, distinct point alongside the display-suffix one, since they’re really two separate gaps:
- can’t hide the (Hebrew) display annotation, and
- “Calendar on input” doesn’t extend to the free-text entry path.
That’s an interesting spot of bother.
It needs some isolation to determine if the problem is in:
- the Gramps export of alternative calendar dates to GEDCOM as text, or
- the WikiTree import of text dates, or
- the WikiTree display of text dates
Reminds me of the compromised dates when the receiving software did not handle date approximations. Some old genealogy software would “helpfully” fill in a 1 for missing date fields. Which makes me permanently suspicious of any imported event that shows it happened on the 1st and doubly suspicious of those that show January 1st.
Ok, answering my own point about Julian calendar. Gramps shows the correct date and has it tagged as Julian in the gedcom file. However per AI WikiTree only supports Gregorian dates. So I will stay with manually converting and entering the dates in the default format.
Maybe you could put in an enhancement request for this?
I first thought about adding an option to export dates in known calendars in Gregorian. But realized that such an option could result in invisible date creep. (Which frequently affects old-style and new-style “Quaker Dates” in my Tree’s records.)
But what do you think of an option to pre-pend any non-Gregorian date’s formatted display date text string to the beginning of the exported Event description? So it could be retained as a sanity check and anti-drift control.
@emyoulation i had a similar thought, but decided to not voice it. It makes things more complicated. I frequently find two citation records, one with the original Julian date and the other with the Gregorian date. My default from day one was to have my db using the Gregorian dates, so I manually correct Julian dates and enter them as Gregorian. I think I’ll stay with that process. However, I don’t know how others use the different calendars and how the dates would be handled by web sites they interact with.