Time formatting

[Rich]

I have a need to convert time stamps to Unix Epoch and from Unix
Epoch:

For example I need to take a string that looks like:
"2011-01-21T05:17:49Z"
"Jan 11 2011 10:10:10 "
"2011-01-21 10:10:10"

And convert it to unix epoch.

Any Ideas?

Thanks,

Rich

[ziutek]

time package is your friend:

http://golang.org/pkg/time/

[Rich]

I'm new to Go, so even though I was looking at pkg/time it didn't make
much sense to me. I come from a scripting background in TCL / PHP /
Ruby. I am used to seeing something like this in TCL:

% clock scan "2010-12-31 00:00:00"
1293771600

it took me some time to figure out, and to help others who may be
stuck on this I am going to attempt to describe it. As Ziutek stated
pkg/time is your friend here and in pkg/time there is a command called
Parse, but how it's used isn't quite clear -- at least to me -- from
the pkg/time.

func Parse

func Parse(alayout, avalue string) (*Time, os.Error)

At first I thought alayout was the format I wanted to get out from
time.Parse To translate this "alayout" is a description of "avalue
string", the os.Error is captured by a second variable in case the
time can't be parsed.2010-12-21T05:17:49Z In my case I needed an
RFC3339 date stamp, so the commands for this are

ztime,err := time.Parse(time.RFC3339,"2011-02-01T12:32:40-05:00" )
if err == nil {
zseconds:= ztime.Seconds()
println("RFC3339 to Epoch: ",zseconds)
} else {
println("You've an error in your time string.")
}

for the 'alayout' this uses a predefined RFC3339, see format.go for
how to format a string if you need something different. For example,
if I needed to parse "2011-02-01 12:00:21" there isn't a default
layout for this, or I've seen in some log files all the numbers mushed
together like this: "20110201120021" (date +%Y%m%d%H%M%S). For Go's
time.Parse the commands would be like this:

zlayout:="2006-01-02 15:04:05"
ztime,error:=time.Parse(zlayout,"2011-02-01 12:00:21")

Or for them all together:
zlayout:="20060102150405"
ztime,error:=time.Parse(zlayout,"20110201120021")

[ziutek]

For alayout you need to use values of following consts:

stdLongMonth = "January"
stdMonth = "Jan"
stdNumMonth = "1"
stdZeroMonth = "01"
stdLongWeekDay = "Monday"
stdWeekDay = "Mon"
stdDay = "2"
stdUnderDay = "_2"
stdZeroDay = "02"
stdHour = "15"
stdHour12 = "3"
stdZeroHour12 = "03"
stdMinute = "4"
stdZeroMinute = "04"
stdSecond = "5"
stdZeroSecond = "05"
stdLongYear = "2006"
stdYear = "06"
stdPM = "PM"
stdpm = "pm"
stdTZ = "MST"
stdISO8601TZ = "Z0700" // prints Z for UTC
stdISO8601ColonTZ = "Z07:00" // prints Z for UTC
stdNumTZ = "-0700" // always numeric
stdNumShortTZ = "-07" // always numeric
stdNumColonTZ = "-07:00" // always numeric


time.RFC3339 format looks like: "2006-01-02T15:04:05Z07:00"

So If you need format of date command '+%Y-%m-%d %H:%M:%S' you should
use:

alayout := "2006-01-02 15:04:05"

[Rich]

It might be nice if one day someone did either an addition to the
existing time functions or another pkg to implement the Unix Date
style +% format. I'd do this but I am still trying to get my head
wrapped around this programming language as it is. :)

[ziutek]

It is a litle hard to remember format used by Go time package. But if
you read the code written by someone and you find something like this:

alayout := "2006-01-02 15:04:05"

you exactly know what a format it is because it looks exactly like the
date/time in this format.

[Rob 'Commander' Pike]

On Feb 1, 2011, at 3:18 PM, Rich wrote:

> It might be nice if one day someone did either an addition to the
> existing time functions or another pkg to implement the Unix Date
> style +% format. I'd do this but I am still trying to get my head
> wrapped around this programming language as it is. :)

Oh, I hope not. The API in Go is much nicer.

-rob

[David Roundy]

I agree that the Go time API is very nice, but I can't help but wonder
whether there will arise issues due to the lack of an escape
possibility. e.g. what if you wanted the standard date as:

1/2 Monster TEAMSTER SHIPMENT 2006

Would the morning of February third in my timezone show up as

2/3 Thuster TEAPSTER SHIAMENT 2011

This is obviously a contrived example, but I can easily imagine
scenarios where numbers 1-7 might be used, or underscores might be
desired in a date in ambiguous locations.

I suppose the answer would be to call Format twice and concatenate the
strings together with the objectionable portions. Is there a better
answer than that, or a good reason why this kind of silliness won't
happen?

David

[Russ Cox]

> This is obviously a contrived example, but I can easily imagine
> scenarios where numbers 1-7 might be used, or underscores might be
> desired in a date in ambiguous locations.
>
> I suppose the answer would be to call Format twice and concatenate the
> strings together with the objectionable portions.  Is there a better
> answer than that, or a good reason why this kind of silliness won't
> happen?

That's not the right question. The question is whether the complexity
added by trying to handle another case is balanced by the frequency
of that case coming up in practice. I am sure that the early idea for
strftime was simple: it was easier to remember %m/%d/%y than to
remember the magic constants in
printf("%d/%d/%d", t.tm_mon+1, t.tm_mday, t.tm_year+1900).
But the special cases that have been added make the patterns impossible
for people to interpret without resorting to documentation.

I think the litmus test is that if a function's usage is so hard to
remember that someone is motivated enough to create a domain and
web site whose only purpose is to make it easier to remember where
to find the documentation, then that function is broken. (http://strftime.org/)

Time.Format doesn't need to be the kitchen sink.
If you need more control, there is always fmt.Sprintf.
Unlike C's struct tm, Go's time.Time does not require
the addition of magic constants to turn struct fields into
printable values.

Russ