After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 625177 - hdate_heb return format is incorrect
hdate_heb return format is incorrect
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: General
1.10.x
Other Windows
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2010-07-24 11:57 UTC by dror.pockard
Modified: 2010-07-26 08:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sample text (4.79 KB, image/png)
2010-07-25 17:14 UTC, Andreas J. Guelzow
Details
screenshot of gnuemric window (165.21 KB, image/png)
2010-07-25 17:54 UTC, Andreas J. Guelzow
Details
anotehr Gnumeric screen shot (237.82 KB, image/png)
2010-07-25 19:49 UTC, Andreas J. Guelzow
Details

Description dror.pockard 2010-07-24 11:57:38 UTC
(the value seems correct, though)

this is a minor bug. the dates are readable anyway, it's just semantics.

hebrew days are formatted the following way:
after a single-character day numeral, should print a single quote only.
wrong: ד"' אב התשע
right: ד' אב התשע


after a double-character day numeral, should print nothing. the double quotes are between the two letters.
wrong: י"ג' אב התשע
right: י"ג אב התשע


the year numeral should have (doesn't have to) a double quote before it's last character.
wrong: התשע
right: התש"ע
Comment 1 Andreas J. Guelzow 2010-07-24 16:35:27 UTC
Please provide:

a) the gregorian date corresponding to the hebrew dates in your examples.

b) some references regarding this issue. (The code for this function was contributed so before I can change it I need some evidence that it isn't quite correct beyond, no offense intended. a single person saying so.)
Comment 2 Andreas J. Guelzow 2010-07-24 16:48:23 UTC
I note that there are potentially some more issues:

=hdate_heb(2010,7,24) returns י"ג' אב התשע

while http://www.hebcal.com/converter/ claims it to be

י״ג בְּאָב תש״ע

In just this one example I see an extra double quote far to the left, and one less single quote on teh right, which appears to be what you are referring to.
Moreover there appears to be one less letter in the left most block and one extra letter in teh middle block.

Plus it seems to me that the single and double quotes probably should not be
U+05F3	׳	d7 b3	HEBREW PUNCTUATION GERESH and
U+05F4	״	d7 b4	HEBREW PUNCTUATION GERSHAYIM
rather than single and double quotes
Comment 3 dror.pockard 2010-07-24 22:43:12 UTC
the extra letter 
This a non-issue. it's a prefix meaning "in" or "at", and in this example it means "13 in Ab" (י"ג באב), rather than "13 Ab" (י"ג אב). 
No biggy, but it looks nicer WITH this prefix. The letter is ב and it precedes the month name.

I am not aware of an official opinion about apostroph ("geresh") direction ' or ` seems the same to me.

the more important rule is as I wrote before:
single day letter - have an apostroph right afterwards,
double-letter day - don't have a single quote, but do have double-quote in between
year number (in your example: תשע) should have " before the last letter (תש"ע). In the program, you should treat it as "one before the last character", and the logical display will take care of the rest.


background for those of you who're interested, 
both the above examples above stem from the same "rule": if letters represent an acronym, rather than a whole word, then we're using a " mark in the second-to-last position.  A day and a year numerals behave the same.
e.g.
י"ג - the number thirteen
התש"ע - this year's number (meaning something like 5770)
ת"א - T.A., Tel Aviv (city name abbreviated, short for תל אביב).
but 
תא - is the hebrew word for a "cell"
Comment 4 dror.pockard 2010-07-24 22:47:57 UTC
more examples:
http://www.yeshiva.org.il/calendar/

it's important to note that there's no "strict" rule about it.
you can leave it this way and it'd be Ok.

the more prevalent/popular/accepted form among most of hebrew speakers is the one i stated.
Comment 5 Andreas J. Guelzow 2010-07-25 17:14:33 UTC
Created attachment 166527 [details]
sample text

Hi,

what about the decorations below the first letter of the month name and below (and inside) the month name prefix? Are they desirable, superfluous, ...?


PS:
Looking at the code it is clear that the initial coder tried to cover the " vs " issues and their placement but confused some character vs byte positions and missed some offset.
Comment 6 Andreas J. Guelzow 2010-07-25 17:54:38 UTC
Created attachment 166530 [details]
screenshot of gnuemric window

please comment on the strings shown in this screenshot. I am thin king that I probably should also add the points to the month names, guessing that those who wouldn't normally not used them won't be bothered by them but those that really want them would appreciate them.
Comment 7 Andreas J. Guelzow 2010-07-25 18:46:35 UTC
For some dates it seems that the year is wrong too, eg. 25 October 2010
Comment 8 Andreas J. Guelzow 2010-07-25 18:48:27 UTC
Note that in the released versions 25 October 2010 translates into an invalid pango string, so this is not a trivial bug.
Comment 9 Andreas J. Guelzow 2010-07-25 19:48:06 UTC
The dates are fine,  http://www.hebcal.com/converter/ just seems to drop the thousands.
Comment 10 Andreas J. Guelzow 2010-07-25 19:49:41 UTC
Created attachment 166535 [details]
anotehr Gnumeric screen shot

Please let me know if you see anything wrong with the months on this screenshot or the days on the last screen shot.
Comment 11 Andreas J. Guelzow 2010-07-25 19:55:22 UTC
Fix has been committed. It should be included in 1.10.8.
Comment 12 dror.pockard 2010-07-26 08:56:02 UTC
i revised all your comments.

i think your fix is very good.

the extra dots above and inside the ב letter, e.g. בּ are OK, i see that you undersdtand already who, when and why they are used.

from my personal point of view i don't think they're needed, but... it's there, let's leave it this way. :)

thanks!