Bug 127063

Summary: Calc: After changing date format, screen reader always reports default date format yyyy-mm-dd
Product: LibreOffice Reporter: Victor <surfer0627>
Component: CalcAssignee: Not Assigned <libreoffice-bugs>
Status: RESOLVED WONTFIX    
Severity: normal CC: erack, himajin100000, ilmari.lauhakangas, vsfoote
Priority: medium Keywords: accessibility
Version: unspecified   
Hardware: All   
OS: Windows (All)   
See Also: https://bugs.documentfoundation.org/show_bug.cgi?id=132232
Whiteboard:
Crash report or crash signature: Regression By:

Description Victor 2019-08-21 02:15:41 UTC 
Description:
This case occurs in screen reader Windows Narrator and third party software NVDA.
While user change the date format (E.G. mm-dd), then screen reader still reports the default date format.



Steps to Reproduce:
1. Start Windows Narrator (Windows + Ctrl + Enter).
2. Open Calc.
3. Type date "8/19".
4. Press Ctrl+1 to open Format Cells dialog.
5. Change date format to mm/dd.


Actual Results:
Narrator reports: 2019-08-19 (yyyy/mm/dd)


Expected Results:
Narrator reports: 08-19 (mm/dd)



Reproducible: Always


User Profile Reset: No



Additional Info:
LibreOffice version：6.2.6.2 (x64)
ID：684e730861356e74889dfe6dbddd3562aae2e6ad
OS：Windows 6.1;
language:：zh-TW
Calc: CL
Comment 1 Buovjaga 2020-04-18 17:09:36 UTC 
I was unable to test this because I got a crash. I created a new report and put it in See also.
Comment 2 V Stuart Foote 2020-07-31 14:00:43 UTC 
With 7.0.0b2 on Windows 10 Home 64-bit en-US with NVDA 2019.3.1 installed and sounding.

No crash as for bug 132232

I confirm the format change for the cell applies with the <Ctrl>+1 'Format cells' dialog. But for the MM/DD format or the DD/MM format applied--the AT sounds the date as a full date -- MM/DD/YYYY (maybe as taken from locales 'Date acceptance paatterns'?).

Other date formats are sounded as they are patterned, including YYYY-MM; and *all* including the MM/DD or DD/MM are identified as date formats to the AT.

So, long and short of it there is no real issue here.  The DD/MM or MM/DD are being passed as full format dates (the actual value held in the cell, not the formatting). And the AT is sounding what it receives.

So, NOT A BUG, and not necessary to adjust as use case now is more helpful to AT. 
IMHO => WF