You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Excel, this is displayed like this: "jeudi 25 juillet 2024".
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?
The text was updated successfully, but these errors were encountered:
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)
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
In a workbook created with Excel 365 on a French system, i have this format: "[$-F800]dddd,\ mmmm\ dd,\ yyyy".
In Excel, this is displayed like this: "jeudi 25 juillet 2024".
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?
The text was updated successfully, but these errors were encountered: