Better Date parsing

[Oleku Konko]

Is there a better date parsing in go  ? 

Example 

        01/02/2013 can be "d/m/Y" or "m/d/Y" depending on the location 

The current time.Parse does not offer this flexibility.  Is there any alternative to parse & show data on specific format in go ? 

[Volker Dobler]

time.Parse and time.Format can both handle "d/m/Y" as well as "m/d/Y" (and other formats as well).

What make you believe their flexibility is not enough? 

V. 

[Matt Silverlock]

The documentation for the time package covers specifying your own time format.

http://golang.org/pkg/time/#pkg-examples

> To define your own format, write down what the reference time would look like formatted your way; see the values of constants like ANSIC, StampMicro or Kitchen for examples. The model is to demonstrate what the reference time looks like so that the Format and Parse methods can apply the same transformation to a general time value.

[Kevin Gillette]

time.Parse is that flexible (and although the format strings do not follow the C convention, they are considerably less obscure, especially considering that many languages with C-like date formatting have their own unconventional departures).

As explained in the package documentation, the format string is based on "01/02 03:04:05PM '06 MST".

"d/m/Y" is "02/01/06"

"m/d/Y" is "01/02/06"

If you need other date/time formats, consult the time package documentation.

[Oleku Konko]

Do you think the current method gives the best flexibility ? 

[Matthew Zimmerman]

Yes, I think it's incredibly flexible...

> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Jeremy Wall]

time.Parse allows you to specify which of those formats you want. If you want the library to intelligently guess then you probably won't get an answer from this list that you like. Take a look at the time.Format for what items in the reference time mean.

for instance 01 or Jan is the specifier for a month. 02 is the specifier for a day and so on in the format. It's a little confusing if you are used to %Y or YYYY specifiers. 

[Oleku Konko]

Yeah .. it really confusing and there are a lot of questions in Stackoverflow about this issue .. Developers over the years are used to  Y specifies that is why am suggesting time.Format  & time.FormatFrom .... 

I must confess the correct method is confusing  ... 

[Kevin Gillette]

If the C stdlib always had Go-style date formatting and parsing, then likely you'd find Y/m/d confusing. The C style has a considerable amount of intra-language inconsistency (capitals are usually for time portions of strings, but Y is for 4-digit years) and inter-language inconsistency (looking at http://en.cppreference.com/w/c/chrono/strftime, virtually none of the C++ extended chars match their semantic counterparts in other languages with C-style time handling); and complexity/arbitrariness if you ever need to do more than just ISO-style time strings (off hand, can anyone say what "%a %I%p, %j [%B] of %Y" specifically outputs?), and the C format specifiers are difficult to remember (requiring you to always use a reference when doing anything unusual).

The offshoots with multi-character "YYYY-M-DD" style specifiers are considerably easier to use and remember, but have little or no possibility of including static text in the output. Go's style also has a reduced capacity to include static text, but for normal uses, it's not prohibitive. The only thing that has to be remembered in Go's style is the order of time values. "01/02 03:04:05 '06 -0700" corresponds to [mon, day, hour, min, sec, year, zone]. Specifying the style of each value is the easiest part: the format string should look exactly how you'd like the standard format time to look if it were output, so "3" corresponds to a non-zero-padded hour value based on a 12-hour clock, while " 3", "03", and "15" are alternative styles, none of which need to be explicitly remembered.

[DisposaBoy]

At least in my case or was only confusing because it was new to me . The c-like format is even worse IMHO. If i need any other format than Y-m-d H:i:s then I must consult the documentation every single time and the only reason I know those is because I memorized it from typing that one format soany times

[Kevin Gillette]

Don't you mean H:M:S ?

[Jakob Borg]

2013/8/6 Kevin Gillette <extempor...@gmail.com>:

> The only thing that has to be remembered in Go's style is the order of time
> values. "01/02 03:04:05 '06 -0700" corresponds to [mon, day, hour, min, sec,
> year, zone].

Which is somewhat confusing for many people since there's only two
countries in the world where 01/02 primarily means second of January,
and Belize is one of them. And you also need to remember that this day
is a Monday.

//jb

[Kevin Gillette]

I'm guessing there's some property of that particular date time that makes it more desirable for this kind of thing than, say, "2001-02-03 04:05:06 -0700".

[Rob Pike]

The order of the fields of the default date were chosen because they are the order in which the Unix date command prints them.

-rob

[Oleku Konko]

I think better simple H:M:S is better than any Unix format ... It would be nice this can be reviewed in such a way where you can parse date based on a format and output based on another format

      time , _ := time.Parse("m/d/y",11/11/2013)

      fmt.Println("%s",time.Format("y-M-d") // 2013-November-11 

[roger peppe]

On 7 August 2013 06:00, Rob Pike <r...@golang.org> wrote:

The order of the fields of the default date were chosen because they are the order in which the Unix date command prints them.

The date command on my computer prints the time zone before the

year.

Too late now, but I also wish that the numbers were

ordered by time-significance - easy to remember even if you

aren't using unix.

[DisposaBoy]

Her Magesty's Ship? No - on a more serious note... I had to go check the docs to be sure and I think I got it right the first time

[meta keule]

Have a look at

http://github.com/metakeule/fmtdate

[Oleku Konko]

Nice .. I think there is room for more Improvement , You just need to add 

 date := fmtdate.Parse("DD.MM.YYYY", "2/01/2013)

Nice and simple 

[meta keule]

added it, in fact it's now

    date, err := fmtdate.Parse("D/MM/YYYY", "2/01/2013")

[Oleku Konko]

+1 Well done 

 Just additional Bonus 

        date := fmtdate.Format("T", time.Now()) // Timezone eg. UTC, GMT

        date := fmtdate.Format("Z", time.Now()) // Timezone Offset 

        date := fmtdate.Format("C", time.Now()) // ISO 8601  eg. 2004-02-12T15:19:21+00:00

        date := fmtdate.Format("R", time.Now()) // RFC 2822 eg Thu, 21 Dec 2000 16:01:07 +0200

        date := fmtdate.Format("U", time.Now()) //Unix Epoch eg January 1 1970 00:00:00 GMT 

        date := fmtdate.Format("MY", time.Now()) // MySQL Datetime eg. 1992-12-31 23:59:59.000002

etc. 

Now compulsory but a quick bonus so that you don't have to compose it again ... 

Anyway .. nice and simple 

[Christoph Hack]

It's funny to see how you have written down examples to clarify each of your format codes. I guess it wouldn't have been hard to use Go's reference date for those examples :)

[Oleku Konko]

Hard is not the word ... I find the current format messy ... and if someone  has come up with a simple alternative all i can do is encourage 

[meta keule]

Now that's over the top.
As the description says "based on conventions of Microsoft Excel (TM) ".
That doesn't cover your examples.

Don't forget that you still have constants in the time package like

    time.Now().Format(time.RFC3339)

code completion is your friend....

[Oleku Konko]

What IDE are you using ? 

[meta keule]

sublime text2 with gosublime if that counts as IDE ;-)
for me it is perfect...

[Kevin Gillette]

Seems a bit redundant to add composite specifiers like 'C' for ISO-8601, since they're almost never used in conjunction with other specifiers, and all the common ones are already handled by the stdlib time package.

[Oleku Konko]

It does not have to be used in conjunction with others