• gouest (unregistered)

    This can be easily solved by just specifying a custom format string instead of one of the predefined constants.

    t.AppendFormat(l.bufStream[:0], "2005-01-02T15:04:05.999999999Z")

    (the other WTF is Go's use of a "reference date" to specify a date format string, but I've grown to like it)

  • gouest (unregistered)

    correction...

    This can be easily solved by just specifying a custom format string instead of one of the predefined constants.

    t.AppendFormat(l.bufStream[:0], "2006-01-02T15:04:05.000000000Z")

    (the 0's at the end indicate fixed decimal places using trailing zeroes; nines would represent decimals with no trailing zeroes)

  • (nodebb)

    It's not, on its face, automatically wrong.

    Perhaps not, but it is very close to wrong, on the basis that one of the reasons for the success of things like Python (and others) is the amount of stuff you can do using just the standard library.

  • Pag (unregistered)

    It's short for: Go build your own libraries!

  • (author) in reply to Steve_The_Cynic

    As a counterpoint: what ends up in the class library is harder to change and you can get trapped. Third parties have a harder time getting traction in domains where the standard library has an implementation, even if that implementation is bad. Time and dates prior to Java 8 are a good example, and the C++ STL is an evergreen case.

  • Rob (unregistered)

    Go has fmt.Sprintf that can be used here. Instead of strconv.AppendInt, l.bufStream = append(l.bufStream, fmt.Sprintf("%06dZ", nanos)) can be used instead to append the 6-digit nanos plus the Z in one call.

  • Milo (unregistered)

    Go has robust time formatting functions that would solve this problem perfectly. Throwing shade about the standard library while said standard library does actually have the solution to the issue is a look for sure...

  • Rob (unregistered)
    Comment held for moderation.

Leave a comment on “Going Through Time”

Log In or post as a guest

Replying to comment #689922:

« Return to Article