I read the user guide section about NVDA +F12, do we need to emphasize in the user guide that the reported time will be accurate to the second?

• PASS: Translation comments check.
• PASS: Unit tests.
• FAIL: Lint check. See test results for more information.
• PASS: System tests (tags: installer NVDA).
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/vt3jl2dta7s1lewt/artifacts/output/nvda_snapshot_pr14792-28037,e99c455d.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 1.0,
  INSTALL_END 0.9,
  BUILD_START 0.0,
  BUILD_END 26.6,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.4,
  TEST_START 0.0,
  TEST_END 23.3,
  FINISH_END 0.2

See test results for failed build of commit e99c455dbf

I read the user guide section about NVDA +F12, do we need to emphasize in the user guide that the reported time will be accurate to the second?

I think this is unnecessary. As long as nothing specifically suggests that the time will be reported in hours and minutes only.

I understand NVDA currently has no control over this, but I'm pretty sure the more common long time format in Windows is 9:40:20 am, not 9:40 am and 20 seconds. In fact, in English Australian at least, I don't even have the latter option at all.
I appreciate that having seconds is very beneficial, and I myself have the ability to get used to it. But I just want it acknowledged that this pr is changing the most known, and probably the most used script in NVDA, and therefore will be noticed by everyone.
As much as we want to avoid extra settings, perhaps this is a case where the user needs control, with the default being what we always had.
Though I'm happy to see community opinion on this one.

I understand NVDA currently has no control over this, but I'm pretty sure the more common long time format in Windows is 9:40:20 am, not 9:40 am and 20 seconds. In fact, in English Australian at least, I don't even have the latter option at all.
Yes, you are right, I set the system language to English (United States) The time format reported by nvda is: 9:24:29 AM.

I'll change the description in the PR so more people can understand the change.
As for whether there really needs to be an option to control the default behavior, I think that might be redundant, but I'd like to hear from the community as well.

I updated the 'Description of user facing changes' section in the original description, it should be clearer now and it's easier for community users to know about the change.

I definitely would prefer "9:40 AM and 20 seconds" (or "09:40 and 20 seconds")...

For me as a user of the 24 hour format, 9:40:20 is ok. I don't think we have to bother about people not liking the change as long as the hour and minute come first.

Onn my French localized system, the default time format are the following (24-hour format):

• short format: 09:40
• long format: 09:40:20

Currently, testing with OneCore, eSpeak and IBMTTS, the short format is always reported as "9 heures 40"; in French, "heures" stands for "hours". this is a common way to report time so this is OK. Note that converting colon in "heures" is done at the synth level, it's not an NVDA processing.

The long format "09:40:20" is reported as follows:

• With eSpeak or IBMTTS: "9 heures 40 20"
• With OneCore: "9 heures 40 minutes 20 secondes"

OneCore reporting is very clear. eSpeak/IBMTTS is less clear but still understandable with time = 09:40:20.

However eSpeak/IBMTTS reporting is confusing when reporting the following times:

• "09:00:10" is reported as "9 heures 10" which is commonly understood as "9 hours, 10 minutes" whereas here it is 9 hours and 10 seconds.
• "09:04:20" is reported as "neuf heures quatre vingt" wich can be understood as "9 hours 4 20" but also "9 hours 80" since in French 80 is called "quatre-vingts", which literally means "four times twenty". Of course, 80 minutes or seconds have no sense. But hearing "quatre vingt", a French would immediately understand 80 and only after a while, may understand that it is actually a four followed by a twenty.

Thus, IMO, reporting "09:04:20" is not an option at all.

We can thus opt for the following two options:

1. Use system format for "HH:MM" and append a translatable string for seconds with the word "and" preventing confusion between seconds and minutes.
2. Make translatable the whole string.

I prefer the first solution because:

• It can take advantage of the format defined by the system at least for hours and minutes
• The second solution may be hard to implement with the 12-hour format (AM/PM)

The drawback of the first solution, is that it may be impacted when increasing punctuation level. However it was already the case with current time reporting in NVDA.

If we really want to work around this problem with punctuation level, we may add two new complex symbols in the symbol file: "colon separating hours and minutes" and "colon separating minutes and seconds". This could be made in a subsequent PR in case it cause issues and has to be reverted. I am specifically thinking to other situations where colons are used between digits, e.g. in MAC addresses.

First I was thinking to use the following formatted string:
"{systemTimeFormat} and {seconds} seconds"
systemTimeFormat being replaced with "09:40" and seconds with "20".

However, in German maybe we have issue, with: "09:05:30".
If reported as "09:30 und 5 seconds", may it be misunderstood as "09:35" (depending on the TTS)?
Cc @Adriani90, @bdorer

If this issue is confirmed with German, we may:

• either use "{systemTimeFormat}, and {seconds} seconds" as formatted string, with comma, for all, in order to avoid confusion
• or use "{systemTimeFormat} and {seconds} seconds" anyway, without the comma, but let German translators add the comma in their translation

@CyrilleB79 your example works well with Onecore and Sapi5 synths, but fails with eSpeak. In german eSpeak reports "o'clock" after every : (colon) so like 9 Uhr 5 Uhr 30. For me this is still a good experience. I am not sure if it is even possible to meet all expectations for every language and synth.

Actually I was thinking to use the following string in German "09:05 und 30 Sekunden" (with or without the comma)
Is this a problem?

Note: Strangely eSpeak reports two times "Uhr" in "09:05:30" but only once in "09:40:20". This is not the case in French. So it's probably an issue to report to the German people of eSpeak... a regexp to fix...

Yes unfortunately german language does what most other languages do not do. In german, for example 35 is gramatically spoken as (five and thirty) not (thirty five). That means regardless of the synth, even putting a koma might cause confusions since people would hear (nine o'clock zero five, and thirty seconds) could also mean there are thirty five seconds. It has to have the word "minutes" spoken after the 05, then it would work without problems. But eSpeak does not provide the regexp for "minutes" in german.

I think that having already a more precise reporting of the time would be an improvement is the goal of this PR.

But IMO there is no need to be very rigorous with the seconds. I think that the feature should remain simple.

@Adriani90's proposal with many gestures may land in an add-on but is far more complex for the general audience of NVDA. Also, the layered gestures have not found their way in NVDA for 10 years at least. I think that if they become one day a reality in core, there are many features which would require them before the clock.

@XLTechie your remark about accuracy is exact, and id depends on the speech rate. But as explained before, I do not think that we need such accuracy. The only known way to report time accurately at the second speaking is as it was done in the speaking clock or at the radio: "At the fourth beep, it will be exactly 9 hours 40 minutes and 20 seconds......... beep, beep, beep, beeeeeeeep".

@XLTechie

Are the seconds going to be inaccurate before they are even announced?
This phenomenon exists, but I don't think we need to manually intervene (i.e. increase) the number of seconds being reported.
Because we can never assume how slow or fast a user's NVDA speech is.

Actually Chinese users also prefer the format: "11 Hours 30 Minutes 38 Seconds" instead of 11:30:38 because the latter may depend heavily on the synthesizer.

Definitely agree with @CyrilleB79 about not including this in the form of a layered key stroke/feature. While I like this second-reporting feature, I think it should be kept simple - And it need not be super-accurate to be useful - its mere inclusion makes it a useful feature IMO.

While the above discussion about how this change should be implemented is pretty important to have, I'm wondering if enough thought has been given with regard to why we need this at all.
@michaelDCurran you said:

I appreciate that having seconds is very beneficial, ...

In what cases having seconds announced seems beneficial to you?

My understanding is that NVDA+F12 was created since sighted people can very easily glance at the clock in the system tray to know the time, and for blind users navigating there is much more tedious. However by default clock shows only hours and minutes and to have seconds shown there it is necessary to either use an alternate clock (operating systems before Windows 10), make a registry edit (Windows 10) or enable a particular option on Windows 11. This suggests to me that for most use cases seconds are redundant for sighted people, and this should be no different for blind users.
The argument that if seconds come last they can be easily silenced by pressing control or resuming navigation is valid to some extend, however less "unwanted" speech the better.
The use case presented in the PR and issue description of a short promotion where seconds are important does not sound very realistic to me - in most such cases there is a separate counter on a store's web page otherwise user would be forced to do mental arithmetic even if seconds are reported when checking time.

@lukaszgo1
You wrote:

The use case presented in the PR and issue description of a short promotion where seconds are important does not sound very realistic to me - in most such cases there is a separate counter on a store's web page otherwise user would be forced to do mental arithmetic even if seconds are reported when checking time.

As far as this use case is concerned, the situation I encountered: Yes, the page may contain a counter, and the change of this counter is obvious to non-visually impaired users at a glance.
However, this doesn't seem to be easy to observe at any time for visually impaired users, and in order to observe this, I may have to press the arrow keys frequently to read the latest value of the counter.

lukaszgo1 wrote:

However by default clock shows only hours and minutes and to have seconds shown there it is necessary to either use an alternate clock (operating systems before Windows 10), make a registry edit (Windows 10) or enable a particular option on Windows 11.

Maybe we could make seconds spoken according to that situations (tweak, Windows setting). Sure, the feature would be less notified though... I was quite disappointed, time ago, when I applied the tweak and discover then that NVDA ignored it.

I fully support this solution which follows a better integration with Windows and which becomes the norm with Windows 11.

For Windows 7/8 users and the majority of Windows 10 users who do not want to play with the registry, they just can use the clock add-on.

I agree that the change made this way would be less visible. Advertising it via "In process" blog may be a solution to make it more visible. Cc @Qchristensen

I noticed that everyone's discussion is mainly focused on how the speech synthesizer handles the time format of hh:mm:ss,
This doesn't seem to have much to do with this change, i.e. you might encounter this time format in other places besides NVDA+F12.

Can you please implement the method outlined in this discussion, using the Windows registry/settings to decide whether to speak seconds.

However by default clock shows only hours and minutes and to have seconds shown there it is necessary to either use an alternate clock (operating systems before Windows 10), make a registry edit (Windows 10) or enable a particular option on Windows 11.

Maybe we could make seconds spoken according to that situations (tweak, Windows setting). Sure, the feature would be less notified though... I was quite disappointed, time ago, when I applied the tweak and discover then that NVDA ignored it.

I fully support this solution which follows a better integration with Windows and which becomes the norm with Windows 11.

Hi @seanbudd
OK, let me clarify:

1. The next thing to do is to read the value in the registry so that NVDA follows the Windows settings.
2. We don't interfere with how NVDA reports the default format of hh:mm:ss, as mentioned before: this time format is very common, not just encountered in NVDA+F12. If it's a problem, maybe it should be dealt with separately.

Thanks

Yes, that plan sounds good.

The issue is that the process for Windows may vary based on the version of Windows. Tracking Windows documentation in NVDA is really out of our scope. I would rather we introduce an NVDA setting in our settings panel to toggle the registry setting, and document that.

I agree with Sean - I think it would be worth a mention in the user guide. The user guide currently includes NVDA+F12 in the table reporting system information (4.7) where it has the description:

"Pressing once reports the current time, pressing twice reports the date"

I think it would be worth adding something like "The time and date are reported in the format specified in Windows time and date settings". I don't think we need to specify how to get to those time and date settings in Windows.

i also think that this should be added like this and we don't need an option for this, people can just press controle to not hear the second, i like to hear the second.

• PASS: Translation comments check.
• PASS: Unit tests.
• FAIL: Lint check. See test results for more information.
• PASS: System tests (tags: installer NVDA).
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/ocua8ma8fsikmjei/artifacts/output/nvda_snapshot_pr14792-28286,cf580cb9.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 0.8,
  INSTALL_END 0.9,
  BUILD_START 0.0,
  BUILD_END 23.8,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.3,
  TEST_START 0.0,
  TEST_END 21.5,
  FINISH_END 0.2

See test results for failed build of commit cf580cb9ac