> While I got also shocked at first by Go's time formatting, is by far the easiest to learn and memorize once you get it.
I completely agree. I've used strftime and the like for years, and I still can't remember %m vs %M without thinking twice about it, at which point I usually just look at the docs to make sure I'm not making a mistake.
By contrast, as soon as I learned the "trick"[0] behind the canonical date in Go, I had it committed to memory, and I haven't needed to look it up once since.
YMMV, but personally, I'd much rather write "Jan" when I want a three-character month and "January" when I want a full month than try to remember that the former is %a and the latter is %A (...or is it the other way around? Time to check... again!)
I tend to prefer ISO-style dates/times myself... and unless the date+time is tied to a location+event (and not always then), store/transmit as UTC. This leads to far fewer headaches in the long run.
> I still can't remember %m vs %M without thinking twice about it
The time component is "%H:%M:%S" — it's all capitals, and I always think "her majesty's ship" when I type it for some odd reason. At any rate, that's how I remember it.
Once I work out that time component, then the date falls into place: "%m-%d-%Y".
But yes, strftime's formatting strings aren't memorable.
(I'm also a server-side engineer, so I active try to avoid formatting dates into anything other than ISO-8601…)
Nah, parsing a date is a thing that you do usually (depends on your job) like 1 every 2/3 months at best.
Every time I have to pick up the docs because Is day the 1st or month the 1st? Ms and Ns which number? Timezone?
I think that the decision of golang to use this way is really unfortunate and yet more lazy than people that don't want to learn yet another (useless) thing.
Personally, when I first read the spec. for time.Format, I thought "well how bleedin' sensible is that?!" The only thing that annoys me is that it isn't in ISO order (I'd have preferred 2001-02-03 14:05:06 ), but all that you need to remember is "2006-01" and the rest just falls naturally into place. I've seen a couple of "complaints" about this over the last few days, and I just don't understand what the problem is. It's logical and neat.
(03 would make more sense but then there would be issues with 12h vs 24h clock)
then they could even express ISO 8601 week number and the corresponding year. Something which is not possible at the moment. Although more difficult to remember it would be 52 and 1999. (For the 2006 it is 01 and 2006 not distinguishable)
But why would you want to? FSM intended us to use ISO-8601 dates and nothing else. If you disagree, I'll meet you on 18/06/12 at 2:04 to discuss the issue, although you have no way of knowing what date or time that string actually refers to.
We have a perfectly good, unambigious date and time format. It's true that many users are deeply committed to ambiguous formats, but we should at the very least be trying to dissuade them from using them by making ISO formats the default.
I messed up - I meant 2001-02-03 04:05:06 , in which case 2:05PM would be format "4:05PM", (or 16:05) . All that'd happen would be the year and seconds swap order in the "123456" format - but as I said, it's a minor quibble.
when importing dates and time from small systems it always amazes me how they screw them up... do they just ignore known standards for a reason? (favorite was dropping leading zeroes in an otherwise ISO format)
It's unfortunate that languages are so monolithic. You want to make a language that does concurrency differently and you end up having to design date format strings! Sad that we still don't have any kind of common libraries or whatever it might take to just do this a couple of times and let language designers pick and choose the preexisting components they want.
"Sad that we still don't have any kind of common libraries or whatever"
We do have those. In this case the common library is called "libc." In this case (and in a few others) the Go team decided to intentionally avoid providing an interface to this function.
The good news is it would take just a few minutes to add support for go to call strftime directly from libc.
Common libraries in C could easily be used via FFI in most languages; they generally aren't because different languages have different paradigms (you might even say that's their purpose), and translations from one language's idioms into another are always lossy.
Besides, users of a library in language X don't want to have to read language Y to look under the hood.
There are dozens of open source programming languages. If one really just wants to create a language with improved concurrency support, he/she can just take one and modify it – this would work a lot better than relying on ready-made components/libraries which can't be modified.
There are some mature languages with an active "modding" community. Haskell, for example.
> You want to make a language that does concurrency differently and you end up having to design date format strings!
No, you don't. You can use one of the 30 existing ways of formatting dates from other languages. You might have to implement it yourself but you don't have to design it yourself.
This is a symptom of the main problem with Go. Its creators either don't know about or have chosen to ignore most of the last few decades of language design and do their own thing when it doesn't add anything significant. And no, they don't do concurrency differently: coroutines have been around for a long time.
This is one of the big upsides of languages like C# or Java that have a lower-level virtual machine runtime that can be shared across different languages. In fact it was the suffering endured by the Gnome team trying to support different languages on top of C that eventually led to the Mono project.
Unfortunately there are also some downsides to the virtual machine approach but I still think there's a window of opportunity open here for Microsoft if they make the CLR robust and reliable on Mac and Linux.
I, for one, deeply appreciate any project which isn't afraid to do things differently when they decide there's a better way. I see it similar to iOS not supporting Flash, or Angular 2.0 rethinking things.
You can't change everything, but it's what you do differently that gives your project value.
Sure, but date formatting? That's where Go is going to differentiate itself? Even though it still uses a C-like format string? This seems like exactly the kind of area where leveraging the existing conventions would be a no-brainer.
It isn't the format string syntax that is the problem that they're trying to solve. I see this as being an iterative, backwards-incompatible improvement on the existing format convention. Changes in convention don't have to be all or nothing.
I personally love the way it works. This is actually one of my arguments in favor of the golang standard library which is, in my opinion, a great piece of software by itself.
The Go date format is one my huge annoyances about the language (not generics, interface{} magic, or the lack of immutable types). My biggest issue is that despite the fact the designers call Strftime bad because no one remembers the letters, and has to have documentation handy - the Go docs don't even document the magic numbers you have to use.
Why 2006? How do I represent a day? When do I use _2 vs 2? Its very poorly documented and thankfully all I use is RFC3339 and Unix timestamps.
Again, where in the documentation is this listed? Why is the timezone 7 even though its before the year? Did you just make this up? It seems to me that this might just be a happy coincidence in the way you ordered the date.
But I would also observe I missed this documentation myself a couple of times, and I think it probably should have gone on the package documentation, so while I'm linking you to this, I'm not necessarily disagreeing that it's misplaced a bit.
Personally I see no problem with this being a WONTFIX. I wouldn't even have built the flipping thing in the first place. (I might have built the fucking thing, though.)
I generally agree with Cox but "no one remembers
all the letters, so the only way to use it is with documentation in hand."
Huh?
Who can remember the numbers? The only way to use this format is with the documentation.
It is an easier to read and verify format. However if you think a casual user will remember that "02" is hour and "03" is... wait, is 02 hour? Let me check the documentation.
First: neat, funny ("I can now write Go date format strings...you win this time"), and I follow the "sprintf may be awful but at least I know it" argument.
While there's a lot to say for sticking to your language's idioms even when it's a pain, if you really need/want strftime there are third-party libraries:
People who say "he could just use sprintf" are missing the point: this lets you use sprintf while writing idiomatic Go.
If I see a Go programmer import a sprintf library just because he doesn't want to conform to the programming environment, that's going to ruffle some feathers during code review.
Look, I'm not trying to make an argument for how good or bad Go's string formatting is. Tbh I forget both and I find myself back in the documentation either way.
But in this case, you're programming Go already. Better stick with the tools that everyone knows and expects. In .go files, Go code is more readable. In .py, it's not.
People who read your Go code will know Go, and they will be in "Go mode". To them a Go-style date formatting string will make more sense than a sprintf one.
I understand there may be legacy issues from other languages, but in a new language... why on earth would you not take the time to make %p the lower case am/pm and %P - AM/PM?
I think the real lesson here is developers have a warped sense of time and would rather spend relatively much more time building a website to solve a problem than it would just to learn it
That's right. There's already so much that engineers have to keep in mind when programming. The less new stuff (particularly arbitrary stuff) people have to keep in mind when building software, IME, the more likely the software is to be correct. That's why designers typically leverage existing conventions when possible rather than invent new ones. It greatly reduces complexity to bind a newish idea (e.g., a new syntax) onto something they already understand well. This is good because complexity is among the biggest enemies of robust software.
Not so much learn but to retain. Working in a web stack you end up having to juggle something like 5 languages at once (Your server language + SQL + HTML + CSS + JavaScript) not to mention these "micro-languages" like time formatting, imgsrc strings, etc. This is why ORMs and things like node.js are popular - to reduce the burden of dealing with a bunch of different languages.
I agree with you (and upvoted you). The reasons is simple to express emotion and obviously to get attention.
A little bit of history. I don't remember exactly when in the 90's it changed but at a certain point there were actually certain words banned from being used in domain registrations.
>I don't remember exactly when in the 90's it changed but at a certain point there were actually certain words banned from being used in domain registrations.
Isn't that censorship? Maybe that's why it changed...
I can do a lot of things in an hour. I could yell out my window for an hour. I could rant on irc for an hour. I could write a blog post about how pissed I am for an hour. I could register a domain name, make a website, host and publish it on news sites, then track the comments of people who comment on it, in an hour.
I'd rather either patch Go or focus on something positive/productive for an hour.
1- Using names for software that is confusing with names of real things that have nothing to do with it, like Cocoa for a user interface library and so many others.
2- Using the terms a two year old will use when she discovers it is funny and gets attention just for saying dirty words.
In this particular case, this combines both in one. The first thing I thought was: This will have something to do with dating and having casual sex or something. Then you discover that no, it has nothing to do with it, it is just a two year old like mindset creating a "funny"(for him) name for their pet project.
I worked in a hospital for four years with a 50% patient load who were kids, most of who were around two years old (that's when the test I performed had it's greatest effect) and often distressed. You know what the naughty word two-year-olds use is? It's "No". I never heard a two-year-old say 'fuck' or any such derivative, and I saw families from all walks of life.
I'm tired of how moralisers make this kind of bullshit up. If you don't like the language, fine, say that. Say it directly. But this kind of demeaning crap is passive-aggressive - ironically not something that a mature commentary should involve.
That title wouldn't make sense for most of the people in the street. In the best case they would probably ask who's Format (but take my words with a grain of salt as I'm not a native English speaker).
The argument from the issue https://github.com/golang/go/issues/444
> It would be much easier to port preexisting code if you could just copy your time formats over.
It's not really much of an argument, since transforming the sprintf format to Go is a trivial as printing an specific date.