proposal: time: allow scientific notation in ParseDuration

[spakin]

Proposal Details

Issue

I encountered this issue while parsing the output of an application I was working with:

• strconv.ParseFloat accepts numbers expressed in scientific notation. strconv.ParseFloat("3.336e-6", 64), for example, works as expected.
• time.ParseDuration does not accept numbers expressed in scientific notation. time.ParseDuration("3.336e-6s"), for example, fails with unknown unit "e-" in duration "3.336e-6s".

A Go Playground demonstration of this limitation in time.ParseDuration can be found here: https://go.dev/play/p/G-1FveHxpZ3

Proposal

I propose that time.ParseDuration be enhanced to allow durations expressed using scientific notation.

[seankhliao]

What sort of application represents time duration like this?

[spakin]

In this case, it was MiniSat, an old but still often used C++ code. MiniSat normally doesn't output times in scientific notation, but I suspect that it uses printf("%g", …) or similar. On one particular run, it finished in a tiny fraction of a second, output its elapsed time in scientific notation, and caused my Go wrapper to crash.

[benhoyt]

I would be opposed to adding this complexity to ParseDuration. It already has units (a scale, kind of like an exponent, so kind of doubles up that functionality) and this change would make the values harder to read. Plus, ParseDuration is documented clearly to parse a decimal with fraction and unit but not more. It seems like it's intended to parse what Duration.String produces -- and that never produces exponents. So this would only be to parse values produced by other systems. My recommendation is if you have a custom format to parse, use a custom parser.

[jfrech]

Conceptually, time.Duration is fixed-point. Allowing scientific notation may lure one into the false believe that e. g. "1e-10s" is a representable duration.

[spakin]

Conceptually, time.Duration is fixed-point. Allowing scientific notation may lure one into the false believe that e. g. "1e-10s" is a representable duration.

But how is that different from "0.0000000001s", which is equally non-representable?

[jfrech]

"0.0000000001s" looks funky. "100ps" and "1e-10s" don't. The former doesn't parse.

[spakin]

"0.0000000001s" looks funky.

I don't follow. We're talking about parsing input, not producing output. Who cares what inputs look funky? They'll be normalized on output.

"100ps" and "1e-10s" don't. The former doesn't parse.

"0.0000000001s" parses as 0ns, as expected for an integer type with nanosecond resolution. "100ps" doesn't parse because units smaller than nanoseconds aren't recognized. This is already documented:

Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".

Despite time.ParseDuration's input accurately being documented as "a possibly signed sequence of decimal numbers, each with optional fraction, I argue that this violates the Principle of Least Surprise because why should some parts of Go (e.g., strconv.ParseFloat and literal floating-point numbers) accept scientific notation but others not?

My proposal is simply that time.ParseDuration accept the same values that strconv.ParseFloat accepts but followed by one of the preceding units. The documentation would then read,

ParseDuration parses a duration string. A duration string is a floating-point number with a unit suffix, such as "300ms", "-1.5h" or "2h45m". Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".

[jfrech]

I guess my interpretation of Principle of Least Surprise differs from yours, but would you also want time.ParseDuration to accept any of "0xap1us", "0x.dp+0h" or "+InfhNANns"?

[spakin]

I wouldn't expect it to accept "+InfhNANns" because that can't be represented by a time.Duration (int64 nanoseconds). The others, while unlikely ever to be used, ideally should be accepted because they're valid floating-point numbers. Again, why should some parts of Go inconsistently accept different floating-point numbers from other parts of Go?

That said, my main concern is scientific notation because programs in many languages, including Go, have an equivalent of C's printf("%g", …). I encountered a case in the wild of this being used to output a time, which Go can't currently parse because time.Duration processes numbers differently from strconv.ParseFloat when it in fact does not need to.

[glycerine]

This feels like asking to hiding alot of magic and rounding heuristics inside time.ParseDuration(), since there are alot of floating point numbers that will not have an exact int64 nanosecondsrepresentation.

What should ParseDuration() do then? It could hide the sloppy inexact conversion, returning an approximation. Or it could return an error. What are you going to do with the error? Probably fall back on the following preferred approach (below) anyway. What are you going to do with a sloppy inexact conversion? Will you even notice it? Will not noticing it lead to bugs? Some, almost surely. Will the new heuristic be acceptable for all current users of time.ParseDuration()? Unlikely, if they are depending on the current set error producing inputs.

I would much rather read Go application code that makes explicit what is going on, like first using f := strconv.ParseFloat(s, 64) on a string s that has the 's' (for seconds duration) suffix verified and removed, and then deliberately displaying the rounding/conversion to the int64 domain. Then I can readily write tests for the cases that matter to my application, and easily tweak the behaivor to what the application at hand requires.

In other words, it is pretty easy to write in user/application code already, using strconv.ParseFloat() itself, and it would be better practice to do that.

[spakin]

time.ParseDuration already uses floats (see line 1668) and already performs inexact conversions. Consider parsing "0.0000000000005h", for example: https://go.dev/play/p/gvs16-UT0N8

Once again, the core of my proposal is for time.ParseDuration to accept scientific notation so "0.0000000000005h" would be parsed the same as "5e-13h". If going through strconv.ParseFloat further reduces the precision of the conversion to int64 nanoseconds—I don't know that it would—then sacrificing its additional features may be warranted for the proposed enhancement to time.ParseDuration.