Go Date Format(fuckinggodateformat.com)
fuckinggodateformat.com
Go Date Format
http://fuckinggodateformat.com/
89 comments
> 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!)
[0] http://golang.org/pkg/time/#pkg-constants
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!)
[0] http://golang.org/pkg/time/#pkg-constants
> By contrast, as soon as I learned the "trick" http://golang.org/pkg/time/#pkg-constants
Since MST is GMT-0700, the reference time can be thought of as 01/02 03:04:05PM '06 -0700
Such sadness. Using a reversed month/year date as a "reference" when we have ISO 8601. Much american-centrism.
Otherwise I like the trick, but I'm not sure it scales to locale-specific time formats (whereas strftime does a bit with %aAbBxX).
Since MST is GMT-0700, the reference time can be thought of as 01/02 03:04:05PM '06 -0700
Such sadness. Using a reversed month/year date as a "reference" when we have ISO 8601. Much american-centrism.
Otherwise I like the trick, but I'm not sure it scales to locale-specific time formats (whereas strftime does a bit with %aAbBxX).
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.
The line right above that one is the first cited reference format:
Mon Jan 2 15:04:05 MST 2006I know, I'm talking about the mnemonic used to remember this date.
> 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…)
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.
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.
> and the rest just falls naturally into place
No, the timezone string is messed up:
2006-01-02T15:04:05Z07:00
If they had picked
2000-01-02T15:04:05Z06:00
(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)
No, the timezone string is messed up:
2006-01-02T15:04:05Z07:00
If they had picked
2000-01-02T15:04:05Z06:00
(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)
ISO ordering would make expressing time in AM/PM ambiguous, i.e. the format string "2:05PM".
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.
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.
12:34:56 2007-08-09 would work equally, though. (EDIT: oops, no.)
How do I cleanly express single digit minutes?
The format string "4 minutes after 12", is unique, but it's not clear that I could turn "34" into "4". Similar for the hour (12 is now 2).
That would also break the "Print this exact time in the format you're currently using" method of creating a compatible time format string.
The format string "4 minutes after 12", is unique, but it's not clear that I could turn "34" into "4". Similar for the hour (12 is now 2).
That would also break the "Print this exact time in the format you're currently using" method of creating a compatible time format string.
That's not ISO format though.
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.
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.
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.
There are some mature languages with an active "modding" community. Haskell, for example.
Surely what we need, the thing that would make focused innovation easiest, is the ability to implement Go's concurrency model in an existing language?
Which we have. Several groups have done this. eg http://docs.paralleluniverse.co/quasar/
Which we have. Several groups have done this. eg http://docs.paralleluniverse.co/quasar/
> 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.
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.
If you use Go and want strftime then use one of the available libraries: http://godoc.org/?q=strftime
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.
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.
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.
[deleted]
[deleted]
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.
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.
If you ask "Why 2006?" then you missed the point.
Mon Jan 2 15:04:05 -0700 MST 2006
0 1 2 3 4 5 6
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.
Here, directly below the actual listing of the constants: http://golang.org/pkg/time/#pkg-constants
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.
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.
It's in the documentation right where you'd expect it to be. http://golang.org/pkg/time/#pkg-constants
It's in the documentation for the Format method, which is where I'd expect to find it:
http://golang.org/pkg/time/#Time.Format
That it's in order is an intentional mnemonic. I'm not sure why the 7 comes later, but appears earlier.
http://golang.org/pkg/time/#Time.Format
That it's in order is an intentional mnemonic. I'm not sure why the 7 comes later, but appears earlier.
Strangely the non-profanity version http://flippinggodateformat.com still has profanity.
Ha my bad. Fixed :)
It still has profanity, in the form of a link to http://fuckinggodateformat.com/ :)
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.)
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.)
Thanks.
nkozyra(1)
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.
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:
https://github.com/search?l=Go&q=strftime
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:
https://github.com/search?l=Go&q=strftime
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.
But if he uses this, well, I'd be none the wiser.
Readability counts.
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.
But if he uses this, well, I'd be none the wiser.
Readability counts.
> Readability counts.
Oh yeah: `01200602150405`
Oh yeah: `01200602150405`
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.
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.
Why would you pack it like that with no delimiters? If you want something with only digits then use seconds since epoch.
Looks like `mmyyyyddhhmmss`? (I've never seen month-year-day before, that's threw me for a second.)
I just recently had this problem while working with Hugo, a Go static site generator.
Suffice to say, it was not intuitive at all. I had to look at the support forums to learn about this Go eccentricity.
I can't say that I hate it. I could probably get used to it.
Suffice to say, it was not intuitive at all. I had to look at the support forums to learn about this Go eccentricity.
I can't say that I hate it. I could probably get used to it.
[deleted](1)
I was wondering why they didn't borrow java SimpleDateFormat
But then I noticed they decided to tackle the dd-MM-yyyyTHH:mm:ss problem AKA crazy case. Which is kind of noble.
But then I noticed they decided to tackle the dd-MM-yyyyTHH:mm:ss problem AKA crazy case. Which is kind of noble.
[deleted]
[deleted]
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?
TIL that the hardest thing to do in computer science is to learn something new and different.
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.
grey on white, lightgrey on white, yellow on white
my oh my, my slightly blurred vision is having fun
my oh my, my slightly blurred vision is having fun
I'm no designer but that yellow color used on the site is not easy to read.
I appreciate the "flipping" version but why such an obnoxiously immature primary domain?
To be honest, I find your tutting about vulgarity in someone's cheat-sheet to be more obnoxious than the swearing.
I thought that children were the ones not allowed to curse :-)
Same sentiment here. In fact, "flipping" makes more sense, even literally, since it's like "flipping the date format" into Go's.
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.
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...
Isn't that censorship? Maybe that's why it changed...
Who the fuck buys a domain name and sets up a web site just because they're frustrated at a date format? I don't get kids today.
$8/year, for fun. Why not? Probably took an hour to do.
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.
Call me crazy.
I'd rather either patch Go or focus on something positive/productive for an hour.
Call me crazy.
There are two thing I don't like in IT:
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.
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.
Using the terms a two year old will use
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.
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.
>Using the terms a two year old will use when she discovers it is funny and gets attention just for saying dirty words.
So, preffering what a prude 50 year old from some place with a strong puritan culture would want to see.
So, preffering what a prude 50 year old from some place with a strong puritan culture would want to see.
For me puritan culture is exactly what makes someone believe this is funny when it is not.
A kid does not find funny what it is not "tabu" or "forbidden".
A kid does not find funny what it is not "tabu" or "forbidden".
> having casual sex
What?
Also, have you tried http://flippinggodateformat.com/ ? It seems they took your considerations into account.
What?
Also, have you tried http://flippinggodateformat.com/ ? It seems they took your considerations into account.
What?
The words "Go"(to go, not the language), "Date"(having a date), and "fucking" in the same place.
Those words have different meanings, and in fact those meanings are the normal meaning for most of the people in the street.
The words "Go"(to go, not the language), "Date"(having a date), and "fucking" in the same place.
Those words have different meanings, and in fact those meanings are the normal meaning for most of the people in the street.
It must have been terrible for you to be confused for those few seconds.
> most of the people in the street
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).
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).
It is interesting that I get downvoted by this.
I suppose some people are offended by my words, but by using inappropriate words on a HN tittle offends me and other people too.
I suppose some people are offended by my words, but by using inappropriate words on a HN tittle offends me and other people too.
I don't think people were offended by your words, they just didn't like that you implied that all of IT was immature.
They may also not have understood how you were offended by the article.
They may also not have understood how you were offended by the article.
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.