You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think we should make 05.999 accept fractional
seconds the same way that 05 does.
---------- Forwarded message ----------
From: Jonathan Gold <jgold.bg@gmail.com>
Date: Wed, Apr 11, 2012 at 10:42
Subject: [go-nuts] Time parsing surprise -- worth a doc clarification?
To: golang-nuts@googlegroups.com
I was surprised to find that a string generated by time.Format() using layout
time.RFC3339Nano would not successfully parse using time.Parse() with that same
layout, but that it would parse using layout time.RFC3339 (sans "Nano").
After digging deeper into the docs though I understood why:
// A decimal point followed by one or more zeros represents a fractional
// second, printed to the given number of decimal places. A decimal point
// followed by one or more nines represents a fractional second, printed to
// the given number of decimal places, with trailing zeros removed.
// When parsing (only), the input may contain a fractional second
// field immediately after the seconds field, even if the layout does not
// signify its presence. In that case a decimal point followed by a maximal
// series of digits is parsed as a fractional second.
So, I grant that the library is correct (and awesome!), but found it nontheless
counterintuitive in this regard. Can I submit a patch to the docs above,
perhaps amending them something like:
...
// signify its presence. In that case a decimal point followed by a maximal
// series of digits is parsed as a fractional second.
//
// Note that this may lead to some subtle behaviors. In particular, a string
// generated by time.Format() using some layout may not parse using that
// same layout. For example, the layout time.RFC3339Nano uses the fractional
// second specifier .999999999, which will generate a fractional string
// .012345 for a time instance with 12345000 nanoseconds (note that trailing
// zeroes are dropped), but this will not parse using that same layout.
// It will however parse using time.RFC3339, which tolerates and correctly
// parses the variable-length fraction string .012345.
jonathan
The text was updated successfully, but these errors were encountered:
The text was updated successfully, but these errors were encountered: