time values >= 24 hours loose hours

[dtscd]

In Excel, you can (for better or worse) format a time as 40:01:02 and it sees that as 40 hours, 1 minute, 2 seconds. Numerically it sees it as a number greater then 1.

This would be fixed in (*parsedNumberFormat).parseTime I believe. I think if this was fixed, the format would need to be scanned for a specific pattern: If the last timecode is surrounded by [] such as [HH]:MM:SS or [MM]:SS then the largest (bracketed) number must be allowed to overflow the normal wrap, so for hours, it if bracketed, it can be >= 24, if minutes are bracketed, then they can be >=60. This is true if [H]:MM:SS or [M]:SS as well. Further more, the assumption that the brackets make the bracketed component disappear if zero appears to be incorrect through testing. If [H]:M:S has a value of "0.01" decimal, then it will format as 0:14:24. Note that the hour is not removed. Lastly, the bracket can be applied to hours or smaller units, but not days or larger units..

Rules:

• Only a single bracketed unit is allowed.
• Bracketed unit could have higher units in the format, but they will by definition will be zero. (eg H:[M]:S is allowed, but H will always be zero)
• Any bracketed unit will not wrap, that is hours can be >= 24 hours, minutes can be >= 60, etc.

Handling this pattern would probably require the following steps:

1. Detect if a hour or smaller unit is bracketed (either single or double).
2. Convert time to a duration from epoc subtraction.
3. Establish bracketed unit time, set higher units as zero, and allow lower unit as normal.

AM/PM

AM/PM markings are a bit strange in this context. AM/PM will default to AM unless the hour unit is greater or equal to 12. However there appears to be a subsequent rule that will display hour as "12" if AM/PM is AM that operates even in a format such as H:[M]:S AM/PM, which is odd as the H is zero by definition, the AM/PM is always set to AM because H is always less then 12, and then the H is adjusted to 12 because the AM/PM is "AM" and Hour is zero.

If this appears acceptable, I could implement.

I could also replace the strings.Replace with a strings.NewReplacer.