• 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)

    @gouest, @Milo: the author of the code has explicitly put in the comments that custom formats are slower and therefore aren't used. No idea how much truth there is in that of course...

  • (nodebb) in reply to Remy Porter

    Counter-counterpoint: JavaScript. Half the reason for the plethora of libraries is that the base language is so tiny that you always need to write something to get what you want, and everyone writes their own thing, and then publishes it as a library.

    (Okay, so the proliferation of UI frameworks is probably due to the low quality of JS devs (like me), but lodash and its ilk are purely due to the tiny standard library.)

  • Duke of New York (unregistered) in reply to Steve_The_Cynic

    Go has a classic printf function that supports width and zero padding.

    That said, it is a design assumption of Go that the its users can and shall write simple code themselves. A busybody library becomes a crutch, and if you've been in front-end dev long enough you remember when "how do I add two numbers with jQuery" was the joke of the day.

  • Assert.WTF (unregistered)

    Their comment says they're not using a custom format because it isn't as optimized as using the RFC3339 format and doing these extra steps. Those steps include multiple math operations, including exponentiation, and multiple casts, conversions, and function calls. Can anyone with knowledge of Go performance testing compare this to using the built-in custom formatter? It feels at least moderately unlikely to me that this is actually faster. I'd be curious if that was a tested assertion or just a feeling.

  • (nodebb)

    If you are worried about which step in your CI/CD process takes the most nanoseconds, I think you may be on the wrong track entirely.

  • L (unregistered)

    TRWTF is that Go standard library has an HTTP server, SQL interface and HTML templates as a result of "the explicit choice to keep the standard library as small as possible"

  • Duke of New York (unregistered)

    In my measurement, a corrected version of today's code is about 20% faster than a custom template. The library's optimization for RFC3339 is a razor-straight code path that doesn't go through the branches of the general formatting function. You have to abuse it pretty badly for it not to be an improvement.

    I don't think there was any particular goal to keep the library small, only that anything in the library should provide value that intrinsic syntax doesn't.

  • (nodebb)

    It couldn't even have been a concurrency bug since the name of the first and third actions are the start and end of something, unless there's an even bigger WTF involved with what they are naming things.

  • jlahd (unregistered) in reply to Assert.WTF

    I ran a quick benchmark with four candidates:

    • Builtin: time.Format(time.RFC3339Nano), which gives the time without leading nanosecond zeros
    • Custom: time.Format("2006-01-02T15:04:05.000000000Z07:00"), which gives the desired result (except that there are nine digits)
    • Manual: The code in this article
    • Sprintf: fmt.Sprintf("%04d-%02d-%02dT%02d:%02d:%02d.%06dZ").

    Results: $ go test -bench=. goos: linux goarch: amd64 pkg: foo.bar/timetime cpu: Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz BenchmarkFormatBuiltin-12 10696587 99.00 ns/op BenchmarkFormatCustom-12 4805121 234.6 ns/op BenchmarkFormatManual-12 11435074 99.58 ns/op BenchmarkFormatSprintf-12 2012674 570.1 ns/op PASS ok foo.bar/timetime 5.564s

    So, it seems that the claim made in the code is valid: It is basically as fast as the builtin version, while using a custom format string is over 100% slower.

  • (nodebb) in reply to sudgy

    That was my thought. The start and end messages are surely being produced on the same thread or that's also a WTF.

    Also a WTF is assuming nanosecond precision also means nanosecond accuracy. I'd be quite surprised if there is any general purpose computer in the World that could get within three orders of magnitude of nanosecond accuracy. Even if you have a nanosecond accurate clock, by the time you've done the system call to get its value, it's out of date.

    Also, if a CI/CD job started and ended in the same second, I would regard that as instantaneous and I'd be checking the logs to find out why it failed.

  • (nodebb)

    I'd be quite surprised if there is any general purpose computer in the World that could get within three orders of magnitude of nanosecond accuracy.

    That's just microsecond accuracy, and that's really quite achievable, especially when the time reading function doesn't actually trigger a system call. (There are other ways to implement it, such as a synchronised hardware clock...)

  • Gilbert (unregistered)

    FULLZ UPDATED 2026 USA UK CANADA SSN NIN SIN INFO with ADDRESS DL Photos front & back with Selfie Passport Photos IT|SP|RUS|AUS|BR|FR amny Countries DL photos available

    Children FUllz USA 2011-2023 Young & Old age FUllz 1930-2010 High CS Pros 700+ Comapny EIN Business Fullz LLC EIN Docs with DL Dead Fullz CC with CVV & Billin Address

    NIN Fullz with Address NIN Fullz with address Sort Code & Account number NIN UK Fullz with DL UK DL photos front back with Selfie UK Passport Photos UK CC fullz

    SIN Fullz with Address Canada DL Photos Front Back with Selfie CA Passpoprt Photos CA Email & Phone Number Active Leads Live CA Fullz

    Germany|Spain|Australia Fullz with Address & DOB Email Leads (Forex, Crypto, Casino, Investors, CEO's, Crypto, Crypto Exchanges) Sweep Stakes Active Combos & B2B Leads

    Tools & Tutorials available Carding Cash Out Scripting Spa--mming SMTP RDP C-panels Shells Web-Mailers SMS & Email Bulk Senders Look-Up Tutorials

    Telegram@killhacks - @ leadsupplier What's App - (+1) 727..788..6129 TG Channel - t.me/leadsproviderworldwide Discord - @ leads.seller VK Messenger - @ leadsupplier Signal - @ killhacks.90 Zangi - 17-7369-4210 Email - exploit.tools4u at gmail dot com https://about.me/gilberthong

    Many Other Stuff available in our shop Active & Live Fullz with guarantee Providing Replacements if anything found invalid Available 24/7

    #fulz #leads #emailleads #sweepstakes #cryptoleads #casinoleads #ssnleads #dlphoto #usaleads #canadaleads #fullzusa #fullzuk #whatsapp #facebook #activeleads #ccshop #cvvdumps #usadocs #highcreditscorefullz #eincompanydocs #kycstuff #infokyc #validfullz #validvendor

Leave a comment on “Going Through Time”

Log In or post as a guest

Replying to comment #689928:

Log Out

« Return to Article