Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Date incorrectly formatted when format code starts with [$-F800] #41

Open
GradlonGwen opened this issue Jul 25, 2024 · 3 comments
Open

Comments

@GradlonGwen
Copy link

In a workbook created with Excel 365 on a French system, i have this format: "[$-F800]dddd,\ mmmm\ dd,\ yyyy".

<numFmt formatCode="[$-F800]dddd\,\ mmmm\ dd\,\ yyyy" numFmtId="164"/>

In Excel, this is displayed like this: "jeudi 25 juillet 2024".

image

Using ExcelNumberFormat API, With the culture set to "Fr-fr" and using the value 45498, the output of the formatting will be: "jeudi, juillet 25, 2024", which is not a valid French representation of a date.

It seems that usually these kind of codes "[$-HEX CODE]" refers to locale code, but in this case, I did not find any formal documentation about this particular code "[$-F800]".
According to exchanges on the internet, it seems to refer to the system long date format (and therefore ignore the formatting coming after the square brackets?).

In ExcelNumberFormat.Parser.ParseSection code, I understand that this code is not interpreted.
Actually, it fells in the TryParseCurrencySymbol case.
Thus, only the part after the square brackets are used for the formatting, resulting in the incorrect string value mentionned above.

I am wondering if someone knows about that, and if they know how to manage such conditions?

@andersnm
Copy link
Owner

Hi, thanks for an interesting and well-researched ticket. I agree with your assessment this refers to a system long date which indeed ignores the formatting coming after the brackets. Can't find any official documentations either, but didn't look too hard.

The library currently mostly ignores the content of [$-XXX]blocks, a solution involves extending the parser to read the all the digits after the dash and add it the format object as a new Section.Lcid member. Then on the formatting side, in the case of SectionType.Date, hardcode to handle Lcid F800 to return the long system date (and F400 for time equivalent)

@GradlonGwen
Copy link
Author

Hi, thanks for the quick response.
I did the changes as you mentionned, but as I am not allowed to create branches in the repo, here is the patch I made:
fixF800.patch

If you prefer, I am OK to submit a PR.

@andersnm
Copy link
Owner

@GradlonGwen Sure, if you fork this repo into your account and create a branch there, then you can create a PR here based on it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants