Bug 105226 - AM/PM locale for it_IT incorrect
Summary: AM/PM locale for it_IT incorrect
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Winfried Donkers
URL:
Whiteboard: target:6.1.0 target:6.0.1
Keywords:
: 105223 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-01-09 21:30 UTC by gmarco
Modified: 2018-01-27 08:33 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
sample test ods (18.83 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-01-09 21:30 UTC, gmarco
Details
time notations (9.96 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-01-20 08:51 UTC, Winfried Donkers
Details
new ods sample (19.84 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-01-25 11:28 UTC, gmarco
Details
new ods sample (20.57 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-01-25 11:30 UTC, gmarco
Details

Note You need to log in before you can comment on or make changes to this bug.
Description gmarco 2017-01-09 21:30:37 UTC
Created attachment 130293 [details]
sample test ods

In the attached "Calc time odssample" you can see and verify my tests:
=ORARIO(0;0;0) cannot anyway display as result "12.00.00m." (cell format "H.MM.SS AM/PM" or "HH.MM.SS AM/PM") where "m." stays for antimeridian.
=ORARIO(0;35;15) cannot anyway display as result "12.35.15m." (cell format "H.MM.SS AM/PM" or "HH.MM.SS AM/PM") where "m." stays for antimeridian.
=ORARIO(24;0;0) cannot anyway display as result "12.00.00m." (cell format "H.MM.SS AM/PM" or "HH.MM.SS AM/PM") where "m." stays for antimeridian.
=ORARIO(24;35;15) cannot anyway display as result "12.35.15m." (cell format "H.MM.SS AM/PM" or "HH.MM.SS AM/PM") where "m." stays for antimeridian.
Further I note that anti and post meridian espress in Calc with the letters "m." and "p." are unusual symbols (in IT we generally use “a.m. or am" and "p.m. or pm" lower or uppercase):
I translate what you can read about at the link http://tp.linux.it/data_ora_valuta.html
TIMEVALUE.
The conventional notation to indicate a time in Italian language is "o:mm:ss"
with the hour expressed in 24-hour format without leading zero.
Expressed in the syntax of the GNU program date(1) becomes: %k:%M:%S
Examples:
13:00:56
4:12
The presence of leading zeros (obtained with dates(1) by replacing the %k with %H) is allowed in case you have the need for alignment issues or ordering.
It should be noted, that only for the alignment motivation, the agreement for date(1) provides for the possibility to use the "_" and "-" modifiers to hide some digit.
Consult the man page for more information.
In case you must use the 12-hour format, morning and afternoon should be rendered as "a.m." and "p.m.". Any other expression (AM/PM or A.M./P.M and so on) is to be avoided.
Also in case you must use the 12-hour format, the issue date(1) to use for the hour is %-I
Comment 1 Buovjaga 2017-01-12 11:02:59 UTC
Setting to NEW.
Comment 2 Winfried Donkers 2018-01-20 08:51:12 UTC
Created attachment 139233 [details]
time notations

I have 3 comments on this bug report:
1. The bug report has nothing to do with the Calc function TIME(). See attachment, where a directly entered time is used.
2. The 12 hour notation does not have 00:00:00, but uses 12:00:00AM/PM. The text in the help file is in 24 hour notation.
3. The p. and m. in the Italian language are local (Italian settings) and do seem to be incorrect.

I would like confirmation of my comments before I change  the subject of the bug report to something like '12 hour time notation in Italian locale incorrect' and remove the bug report from the Calc functions meta bug.
Comment 3 Winfried Donkers 2018-01-20 12:07:49 UTC
(In reply to Winfried Donkers from comment #2)
[...] 
> I would like confirmation of my comments before I change  the subject of the
> bug report to something like '12 hour time notation in Italian locale
> incorrect' and remove the bug report from the Calc functions meta bug.
 (Forgot to set the status to NEEDINFO)
Comment 4 gmarco 2018-01-20 14:11:50 UTC
(In reply to Winfried Donkers from comment #3)
> (In reply to Winfried Donkers from comment #2)
> [...] 
> > I would like confirmation of my comments before I change  the subject of the
> > bug report to something like '12 hour time notation in Italian locale
> > incorrect' and remove the bug report from the Calc functions meta bug.
>  (Forgot to set the status to NEEDINFO)

I think:
- the problem is exactly the same (original post) and depends on a wrong national time conversion
- it was still open in NEW status since 2017-01-12
- you should NOT have changed neither the status nor the original LO version (earliest affected)

I hope some administrator can restore properly.
Comment 5 gmarco 2018-01-20 15:04:29 UTC
errata corrige:
you have not changed the version, I meant to say that not even the version should be modified.
Comment 6 Winfried Donkers 2018-01-20 15:26:35 UTC
(In reply to gmarco from comment #4)
> (In reply to Winfried Donkers from comment #3)
> > (In reply to Winfried Donkers from comment #2)
> > [...] 
> > > I would like confirmation of my comments before I change  the subject of the
> > > bug report to something like '12 hour time notation in Italian locale
> > > incorrect' and remove the bug report from the Calc functions meta bug.
> >  (Forgot to set the status to NEEDINFO)
> 
> I think:
> - the problem is exactly the same (original post) and depends on a wrong
> national time conversion
> - it was still open in NEW status since 2017-01-12
> - you should NOT have changed neither the status nor the original LO version
> (earliest affected)
> 
> I hope some administrator can restore properly.

@gmarco:
I have changed the status to NEEDINFO in order to make clear to everybody that there is an open question that affects the bug report handling/fixing. I also changed the O/S from Windows to All, as the problem also occurs on Linux. I am able to change status because I fix bugs.
My main concern is that this bug report is currently listed as a Calc function bugs and not as a locale time notation problem.

I think we both agree on the exact problem: the notation/presentation of 12-hour time values in Italian language/locale is wrong.
My intention still is to: set the status back to NEW, change the bug report title to '12 hour time notation in Italian locale incorrect', remove the Calc-function metabug blocker and add a locale notation metabug blocker if I can find a metabug (or similar).
For the change of description of the real problem I asked confirmation to make sure I didn't forget anything.
Should it have been a TIME() function bug, I would have tried to fix it, I concentrate on Calc function code (that's how I came across this bug report). As it is not, I can probably not fix it. Therefore it is important that the bug report is labelled correctly as a locale time notation bug.

Does this explain my changes for you? And if so, do you agree with my intention above?
Comment 7 Winfried Donkers 2018-01-20 18:19:03 UTC
I found the cause: the a.m. and p.m. symbols are defined incorrectly for locale it_IT. Sardinian (sc_IT) for example is correct.
After testing the fix I will submit the patch.
Comment 8 gmarco 2018-01-20 22:43:28 UTC
(In reply to Winfried Donkers from comment #6)
> > 
> Does this explain my changes for you? And if so, do you agree with my
> intention above?

If you are enabled to do it, no problem, bye.
Comment 9 Commit Notification 2018-01-22 12:48:13 UTC
Winfried Donkers committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b6c0356ac9d59a4599d15f8d2f001d39010b3e48

tdf#105226 fix incorrect AM/PM symbol in locale it_IT.

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2018-01-22 18:54:27 UTC
Winfried Donkers committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9a86daba30a60f478c4d2c430cd5607301e4f252&h=libreoffice-6-0

tdf#105226 fix incorrect AM/PM symbol in locale it_IT.

It will be available in 6.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Winfried Donkers 2018-01-23 15:36:02 UTC
*** Bug 105223 has been marked as a duplicate of this bug. ***
Comment 12 gmarco 2018-01-23 21:25:49 UTC
(In reply to Winfried Donkers from comment #11)
> *** Bug 105223 has been marked as a duplicate of this bug. ***

OK, you closed bug 105223 as a duplicate of this 105226, the two reports have two different functions (TIME.VALUE and TIME) but probably the source of the error is the same.

You changed the title of this report, but I would like to point out that the AM / PM translation is not the only problem.
As indicated it is also wrong:
=TIME(0;0;0) and =TIME(24;0;0) can not anyway display as result "12.00.00m." nor "12.00.00AM"
=TIME(0;35;15) and =TIME(24;35;15) can not anyway display as result "12.35.15m." nor "12.35.150AM"
Comment 13 Adolfo Jayme Barrientos 2018-01-24 05:17:17 UTC
@gmarco: one bug report per issue, please.
Comment 14 Winfried Donkers 2018-01-24 07:20:26 UTC
(In reply to gmarco from comment #12)
> (In reply to Winfried Donkers from comment #11)
> > *** Bug 105223 has been marked as a duplicate of this bug. ***
> 
> OK, you closed bug 105223 as a duplicate of this 105226, the two reports
> have two different functions (TIME.VALUE and TIME) but probably the source
> of the error is the same.
> 
> You changed the title of this report, but I would like to point out that the
> AM / PM translation is not the only problem.
> As indicated it is also wrong:
> =TIME(0;0;0) and =TIME(24;0;0) can not anyway display as result "12.00.00m."
> nor "12.00.00AM"
> =TIME(0;35;15) and =TIME(24;35;15) can not anyway display as result
> "12.35.15m." nor "12.35.150AM"

See comment 2 (item 2 of the remarks) and it's attachment.
Should you still think there is a bug with AM/PM presentation for 00:00:00/24:00:00, please create a new bug report solely for this.

You can verify if the bug is fixed for the it_IT locale (with any time function you like) with a daily build of version 6-0 or master (build of 23 January or later). To show that you have verified the fix, you can then set the status of the bug report to RESOLVED/VERIFIED.
Comment 15 gmarco 2018-01-24 09:22:02 UTC
(In reply to Winfried Donkers from comment #14)
 
> You can verify if the bug is fixed for the it_IT locale (with any time
> function you like) with a daily build of version 6-0 or master (build of 23
> January or later). To show that you have verified the fix, you can then set
> the status of the bug report to RESOLVED/VERIFIED.

I use Windows10 and I can not install the daily builds (so I understand), if I install LO 6.0 beta it will replace my actual installation, how can I test the fix and report feedback?
Comment 16 gmarco 2018-01-24 09:25:19 UTC
(In reply to Adolfo Jayme from comment #13)
> @gmarco: one bug report per issue, please.

YES, and so it is (see my first post)
Comment 17 Buovjaga 2018-01-24 09:52:53 UTC
(In reply to gmarco from comment #15)
> I use Windows10 and I can not install the daily builds (so I understand), if
> I install LO 6.0 beta it will replace my actual installation, how can I test
> the fix and report feedback?

What is the problem with daily builds? Here is one that is built on 24 Jan: https://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/current/
Comment 18 gmarco 2018-01-24 10:37:03 UTC
(In reply to Buovjaga from comment #17)
> (In reply to gmarco from comment #15)
> What is the problem with daily builds? Here is one that is built on 24 Jan:
> https://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/current/

I had read: RC builds are in configuration and will replace your existing LibreOffice installation!
Can I install these without altering the version in use?
Which of the two?
Libo-master64 ~ 2018-01-23_23.04.23_LibreOfficeDev_6.1.0.0.alpha0_Win_x64.msi
Libo-master64 ~ 2018-01-23_23.04.23_LibreOfficeDev_6.1.0.0.alpha0_Win_x64_sdk.msi
Comment 19 Buovjaga 2018-01-24 11:30:18 UTC
(In reply to gmarco from comment #18)
> I had read: RC builds are in configuration and will replace your existing
> LibreOffice installation!
> Can I install these without altering the version in use?
> Which of the two?
> Libo-master64 ~ 2018-01-23_23.04.23_LibreOfficeDev_6.1.0.0.alpha0_Win_x64.msi
> Libo-master64 ~
> 2018-01-23_23.04.23_LibreOfficeDev_6.1.0.0.alpha0_Win_x64_sdk.msi

Daily builds always install in parallel. They are not the same as RC builds.

LibreOfficeDev_6.1.0.0.alpha0_Win_x64.msi is the one you want.
The other one is the SDK.
Comment 20 gmarco 2018-01-25 11:28:25 UTC
Created attachment 139359 [details]
new ods sample

it is the old one tested in version 6.1.0.0.alpha0_Win_x64
Comment 21 gmarco 2018-01-25 11:30:08 UTC
Created attachment 139360 [details]
new ods sample

it is the old one tested in version 6.1.0.0.alpha0_Win_x64
Comment 22 gmarco 2018-01-25 11:34:52 UTC
Tested in version 6.1.0.0.alpha0_Win_x64
I think not all resolved (see comments in new attachments)
I cannot test helps as I cannot access them in the alpha version
Comment 23 Winfried Donkers 2018-01-25 14:35:05 UTC
(In reply to gmarco from comment #22)
> Tested in version 6.1.0.0.alpha0_Win_x64
> I think not all resolved (see comments in new attachments)

I see 2 main comments:

a. a dot is used as separator in times and should be a colon. This is specific for the general Italian locale (it_IT). I overlooked that and will fix that asap;

b. midnight in 12 hour notation is shown as 12:00:00AM (English notation). You state that that is wrong. However, 
 https://en.wikipedia.org/wiki/12-hour_clock
and
 https://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight
are quite clear that midnight is 12:00:00AM and noon is 12:00:00PM (English notation). So I have no intention to change that.

> I cannot test helps as I cannot access them in the alpha version

I do not understand what you mean, nothing has been changed in the help text.
Comment 24 Commit Notification 2018-01-25 20:32:10 UTC
Winfried Donkers committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c97d67631724c29fa665c5f0aaad0a0fd9a061ee

tdf#105226 follow up: change time separator for locale it_IT.

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 25 gmarco 2018-01-26 08:03:01 UTC
(In reply to Winfried Donkers from comment #23)
> (In reply to gmarco from comment #22)
> > Tested in version 6.1.0.0.alpha0_Win_x64
> > I think not all resolved (see comments in new attachments)
> 
> I see 2 main comments:
> 
> a. a dot is used as separator in times and should be a colon. This is
> specific for the general Italian locale (it_IT). I overlooked that and will
> fix that asap;
> 
> b. midnight in 12 hour notation is shown as 12:00:00AM (English notation).
> You state that that is wrong. However, 
>  https://en.wikipedia.org/wiki/12-hour_clock
> and
>  https://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight
> are quite clear that midnight is 12:00:00AM and noon is 12:00:00PM (English
> notation). So I have no intention to change that.
> 
> > I cannot test helps as I cannot access them in the alpha version
> 
> I do not understand what you mean, nothing has been changed in the help text.

Yes, but look too at
https://en.wikipedia.org/wiki/Midnight
<<  While computers and digital clocks display "12:00 a.m." and "12:00 p.m.", those notations provide no clear and unambiguous way to distinguish between midnight and noon. Strictly speaking, it is actually incorrect to use "a.m." and "p.m." when referring to noon or midnight (12:00).  .... — 12:00:01 p.m. would be the correct notation for "1 second after noon").  >>
and  https://en.wikipedia.org/wiki/12-hour_clock 
<<  The American Heritage Dictionary of the English Language (https://ahdictionary.com/word/search.html?q=AM) has a usage note on this topic: "By convention, 12 AM denotes midnight and 12 PM denotes noon. Because of the potential for confusion, it is advisable to use 12 noon and 12 midnight."  >>
and https://www.nist.gov/pml/time-and-frequency-division/times-day-faqs
<<  Are noon and midnight referred to as 12 a.m. or 12 p.m.?
This is a tricky question because 12 a.m. and 12 p.m. are ambiguous and should not be used.  >>
Then
a.  colon is more usual in IT but colon too is acceptable.

b.  midnight is really a rebus and the representation 12 a.m. is really a nonsense, 00 or 24 would be more pleasant exactly as obtained using a formattting HH.MM.SS.
However I think the following cases should be better reconsidered, particularly if H is followed by significant M (0.35 or 24.35):
=ORARIO(0;0;0)  returns	12.00.00 a.m. if format is HH.MM.SS AM/PM but 00.00.00  if format is HH.MM.SS 
=ORARIO(24;0;0)  returns 12.00.00 a.m. (a.m. when 24 ?) if format is HH.MM.SS AM/PM but 0.00.00  if format is HH.MM.SS
=ORARIO(0;35;15)  returns 12.35.15 a.m. (12 ?) if format is HH.MM.SS AM/PM but 00.35.15  if format is HH.MM.SS (
=ORARIO(24;35;15)  returns 12.35.15 a.m. (12 ?) if format is HH.MM.SS AM/PM but 00.35.15  if format is HH.MM.SS 
=ORARIO.VALORE(“00.00”)  returns 12.00.00 a.m. if format is HH.MM.SS AM/PM but 00.00.00  if format is HH.MM.SS
=ORARIO.VALORE("24.00”)  returns 12.00.00 a.m. (a.m. when 24 ?) if format is HH.MM.SS AM/PM but 00.00.00  if format is HH.MM.SS 
=ORARIO.VALORE(“00.35”)  returns 12.35.00 a.m. (12 ?) if format is HH.MM.SS AM/PM but 00.35.00  if format is HH.MM.SS
=ORARIO.VALORE(“24.35”)  returns 12.35.00 a.m. (12 ?) if format is HH.MM.SS AM/PM but 00.35.00  if format is HH.MM.SS

c.  I mean that alpha has no local help and if I look at the online help (IT and EN too) nothing yet has changed in the examples:
TIME(0;0;0) returns 00:00:00 (colons instead of dots)
TIME(4;20;4) returns 04:20:04 (colons instead of dots)
TIMEVALUE(("4PM") returns 16:00:00  (it should be "4 p.m." and a return with colons instead of dots)
TIMEVALUE(("24:00") returns 00:00:00 it should use colons instead of dots in both the function and the return)
If you like it should be a distinct documentation bug.
Comment 26 Commit Notification 2018-01-26 09:17:04 UTC
Winfried Donkers committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ac709f527bbe0e871bafef9b8f0993f4b865bbc4&h=libreoffice-6-0

tdf#105226 follow up: change time separator for locale it_IT.

It will be available in 6.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 27 Winfried Donkers 2018-01-26 13:34:33 UTC
(In reply to gmarco from comment #25)
> b.  midnight is really a rebus and the representation 12 a.m. is really a
> nonsense, 00 or 24 would be more pleasant exactly as obtained using a
> formattting HH.MM.SS.
> However I think the following cases should be better reconsidered,
> particularly if H is followed by significant M (0.35 or 24.35):
> =ORARIO(0;0;0)  returns	12.00.00 a.m. if format is HH.MM.SS AM/PM but
> 00.00.00  if format is HH.MM.SS 
> =ORARIO(24;0;0)  returns 12.00.00 a.m. (a.m. when 24 ?) if format is
> HH.MM.SS AM/PM but 0.00.00  if format is HH.MM.SS
> =ORARIO(0;35;15)  returns 12.35.15 a.m. (12 ?) if format is HH.MM.SS AM/PM
> but 00.35.15  if format is HH.MM.SS (
> =ORARIO(24;35;15)  returns 12.35.15 a.m. (12 ?) if format is HH.MM.SS AM/PM
> but 00.35.15  if format is HH.MM.SS 
> =ORARIO.VALORE(“00.00”)  returns 12.00.00 a.m. if format is HH.MM.SS AM/PM
> but 00.00.00  if format is HH.MM.SS
> =ORARIO.VALORE("24.00”)  returns 12.00.00 a.m. (a.m. when 24 ?) if format is
> HH.MM.SS AM/PM but 00.00.00  if format is HH.MM.SS 
> =ORARIO.VALORE(“00.35”)  returns 12.35.00 a.m. (12 ?) if format is HH.MM.SS
> AM/PM but 00.35.00  if format is HH.MM.SS
> =ORARIO.VALORE(“24.35”)  returns 12.35.00 a.m. (12 ?) if format is HH.MM.SS
> AM/PM but 00.35.00  if format is HH.MM.SS

If you want the AM/PM time notation changed, please create a separate bug report about AM/PM time notation. 
Personally I fully agree that AM/PM notation is confusing from 00:00/24:00 up to 00:59, but that has nothing to do with LibreOffice.

 
> c.  I mean that alpha has no local help and if I look at the online help (IT
> and EN too) nothing yet has changed in the examples:
> TIME(0;0;0) returns 00:00:00 (colons instead of dots)
> TIME(4;20;4) returns 04:20:04 (colons instead of dots)
> TIMEVALUE(("4PM") returns 16:00:00  (it should be "4 p.m." and a return with
> colons instead of dots)
> TIMEVALUE(("24:00") returns 00:00:00 it should use colons instead of dots in
> both the function and the return)
> If you like it should be a distinct documentation bug.

Yes, if you want the help text to be more clear, please create a separate bug report about this. AFAICS it concerns the 'base' help text in English and all translated help texts.

I regard this bug report as closed.
Comment 28 gmarco 2018-01-26 23:02:51 UTC
(In reply to Winfried Donkers from comment #27)
> 
> I regard this bug report as closed.

OK  (if there is no possibility to improve the representation)  but see how in CALC a report as an hourly agenda looks like:
in col.A the first line should be the last (should it 24:00;00)
in col.B the first 4 rows are misleading, it would not happen if the HH digits were 24 instead of 12 for the 1st row, 00 for the others and 12a.m. for the 7th. 

  text	        HH:MM:SS		  text	      HH:MM:SS AM/PM
	sorted ascending 			    sorted ascending 
	           A			                     B
24;00;00	00:00:00		24;00;00	12:00:00 a.m.
00;00;00	00:00:00		00;00;00	12:00:00 a.m.
00;01;00	00:01:00		00;01;00	12:01:00 a.m.
00;59;59	00:59:59		00;59;59	12:59:59 a.m.
01;00;00	01:00:00		01;00;00	01:00:00 a.m.
11;59;59	11:59:59		11;59;59	11:59:59 a.m.
12;00;00	12:00:00		12;00;00	12:00:00 p.m.
13;00;00	13:00:00		13;00;00	01:00:00 p.m.
23;59;01	23:59:01		23;59;01	11:59:01 p.m.
23;59;59	23:59:59		23;59;59	11:59:59 p.m.

Then, about documentation, I don't know how it is now the local IT but I no more need.
Thanks anyway.
Comment 29 Buovjaga 2018-01-27 08:33:58 UTC
(In reply to gmarco from comment #28)
> (In reply to Winfried Donkers from comment #27)
> > 
> > I regard this bug report as closed.
> 
> OK  (if there is no possibility to improve the representation)

To quote Winfried: "If you want the AM/PM time notation changed, please create a separate bug report about AM/PM time notation."