lib/52101: parsedate does not handle 12:30 am or 12:30 pm correctly

[kre%munnari.OZ.AU@localhost]

>Number:         52101
>Category:       lib
>Synopsis:       parsedate does not handle 12:30 am or 12:30 pm correctly
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 21 18:50:00 +0000 2017
>Originator:     Robert Elz
>Release:        NetBSD 7.99.65 (all for a long time)
>Organization:
>Environment:
System: NetBSD andromeda.noi.kre.to 7.99.43 NetBSD 7.99.43 (VBOX64-1.2-20161202) #21: Sat Dec 3 00:43:51 ICT 2016 kre%magnolia.noi.kre.to@localhost:/usr/obj/current/kernels/amd64/VBOX64 amd64
Architecture: x86_64
Machine: amd64
>Description:
	date -d '12:30 am'
	Wed Mar 22 12:30:00 ICT 2017

	date -d '12:30 pm'
	date: Cannot parse `12:30 pm'

On older NetBSD there's less error checking in parsedate(), and
instead of the error, we get ...

	date -d '12:30 pm' 
	Thu Mar 23 00:30:00 ICT 2017

These examples were all run (approximately) at
	date
	Wed Mar 22 01:36:15 ICT 2017
which is
	date -u
	Tue Mar 21 18:36:01 UTC 2017

>How-To-Repeat:
	Just run the examples above.

	The problem is that parsedate() implements 'am' and 'pm"
	in an extremely crude way, just:
		if pm is speficied, add 12 to the hours value, otherwise,
		use the hours unchanged.

	That's fine for '1 am' and '1 pm' but causes the results above
	when hours == 12.

>Fix:
	Coming soon...   First, the ATF tests will be extended to
	look for this case (and expected to fail).  This PR is so
	there's a number to go in the "expected to fail" message...

	Then parsedate will be fixed - and at the same time support
	will be added for "12 noon" and "12 midnight" - it would be
	nice if "12 am" and "12 pm" could be made errors (since they
	are technically meaningless) but everyone (and their dogs) uses
	"12 am" to mean "12 midnight", and "12 pm" to mean "12 noon",
	so making them be errors would be counter productive (but
	they should produce the intended results, not bogus ones.)

	[Aside: I noticed the parsing error that is the subject of the
	PR when my testing of code for noon/midnight was failing...]