what is the origin of Go's reference time system?

[Ayan George]

I'm really impressed by the simplicity of Go's time formatting and parsing mechanisms -- particularly when compared with strftim().

Does anyone know the origin or history of it?  Is there a precedent for using reference layouts that include string like 2006, January, etc.?

Do other languages provide something similar or is this completely unique to Go?

Can someone point me to or describe the history of Go's time formatting method?

-ayan

[Rob Pike]

I believe it's unique. I thought of it one day while walking home. It is inspired by the way Cobol picture clauses represent number formats. (That said, I've never programmed in Cobol.)

-rob

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/baa45515-cde6-4c7c-a34c-54ddf7da807en%40googlegroups.com.

[Alex Besogonov]

Can we perhaps get a bit more unambiguous reference date for it?

[Rob Pike]

Not without breaking compatibility.

-rob

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c8f3bc05-3b30-45ad-9e7a-4c12481494d8n%40googlegroups.com.

[Alex Besogonov]

It’s possible to use a different method name (“FormatNew”?) to avoid back compat issues. But yeah, it would be a bit ugly.

It might make sense to revisit this if Go ever grows i18n for datetimes.

[Marvin Renich]

* Ayan George <ay...@ayan.net> [221026 13:51]:

>
> I'm really impressed by the simplicity of Go's time formatting and parsing
> mechanisms -- particularly when compared with strftim().

I have to disagree. This is the most egregious design flaw of the
standard library, and the second worst design flaw of the language.

First, every single programmer who has used any other C-like language
knows %y %m %d %H %M %S. For English speakers (native or as a second
language), these have mnemonic associations with the values they
represent. When writing a strftime format, there is no reason to look
at the man page for common usage.

For Go's Time.Format, it is almost always necessary to refer to the
documentation to get the correct numbers, or to at least think
"month/day hour:minute:second" and then apply numbers to them. When
formatting a date, I almost always want a year; where is that in the
order? Before month (where it should be)? No! Between day and hour as
in typical US formatting? Sorry, wrong again. This is significantly
more cognitive load than using the mnemonics.

And this is just writing code; the cognitive load is even worse when
reading someone else's code, especially when doing a code review and
trying to make sure the other programmer did it correctly.

Second, Go's fmt.Printf uses % escapes for substitutions, but it uses a
completely different syntax for time formatting substitutions.
Really??? For a language that tries to be as simple and consistent as
possible, this doesn't make any sense, especially when there is already
a well-known %-escape model to start with.

Third, and worst of all, there is no way to escape literal digits in the
format string. How do you write the Go equivalent of C's "%A, 4 minutes
after %H:%M"? You either have to call Format twice and combine three
strings, or you have to do string substitution after calling Format.

The picture-style format string is a "cool" idea, but impractical for
real programming and a serious design flaw. I have always wished that I
were able to convince the Go devs to add a new Time.FormatDoneRight that
used %-style formatting. I would not copy C's "lots of letters for
different styles of the same value"; I would use modifiers like "%0m"
for two-digit month. And I would give day-of-year its own letter (why
does day-of-year use the same number as day-of-month?)

...Marvin