@SvenDowideit

I think unix dates are very easy to parse and they are consistent across all platforms and languages. I would rather have the API return the "lowest common denominator" in regards to date formats and let external tools parse and format to whatever format that they require.

If we were to make any time of formatting changes to the data I would rather see that done in the CLI only and not on the serverside.

@crosbymichael the API is still takes and returns the unix epoch seconds - I agree thats the sane programatic interface.

The change I made is to allow the user to specify a date string in the same format as the cli prints to the user (in addition to the epoch seconds).

that way, users of the CLI don't have to read the long list of events with '2013-09-03 15:49:29 +0200 CEST' and then write some code to convert to epoch seconds to use -since

yup, this is CLI only

:)

The CLI code change looks handy to me as a user (assuming it parses well).

Unfortunately I did a big change to the commandline docs structure (and some tweaks to the events docs in particular) that mean the docs part of the PR needs work.

ah yes, now i wonder why github told me this would merge cleanly :)

@crosbymichael @metalivedev re-jiggered :)

LGTM

@SvenDowideit I Updated your title. You need to have the "Closes XXX" part in the body and not the title.

@SvenDowideit

I would expect to input a date without the time stamp. 2013-01-01 but I have to add a lot of data that I don't care about to get events from a certain date.

2012-01-01 01:01:01 -0700 GMT

@crosbymichael yep, I didn't want to write a huge date parsing thing - I was aiming to just cover the cut&paste from the output form.

that said, you did make the think a little more, and wonder what you think of this little ditty:

     if t, err := time.Parse("2006-01-02 15:04:05 -0700 MST"[:len(*since)], *since); err == nil { 

mmm, should I also then get the local timezone, and push that in too? (else the shortened date is given UTC)

so to cater for shortened dates, but still in the user's local tz, we'd need to have something like

    full_format := "2006-01-02 15:04:05 "
    tz_format := "-0700 MST"

    format := full_format
    if len(date) > len(full_format) {
        //user must have specified tz
    } else {
        format = format[:len(date)]
        date = date + time.Now().Format("tz_format")
    }
    format = format + tz_format

hopefully there's a better way to express it - I'm going to sleep on it :)

(playing with ParseInLocation, but I didn't use it last night as it wasn't working in the go playground)

mmm, interestingly, on my chromebox running chrubuntu, i get go version 1, and it tells me time.ParseInLocation is undefined.

pottering over to the other box.... - v1.0.2

and it turns out that time.ParseInLocation is a v1.1 addition, so I'll discard that for now, as the rest of docker works on 1.0

@metalivedev should I add the req for go1.0 formally to the dev-docs (and perhaps a note that the golang docco defaults to 1.1 (or later)?

(ok, talked to shykes, I'll make a new PR for this)

@crosbymichael I've added some code that will assume your local TZ if you don't specify one (as thats what the output does too) so now it will use the fragment you do specify.

One method I've used in other projects to very great success is to have an array of possible time formats in order from most-specific (ie, including the timezone, like time.RFC3339Nano) down to least specific (ie, time.Kitchen), and then, since Go is so speedy at attempting to parse them, just run your input string across the entire list until something matches. This way, you get many different formats for very little extra work, and it becomes trivial to add more.

@tianon i did contemplate that, but I wasn't sure that its worth the docco and code load for the CLI.

mostly, I wanted the user to be able to use the date format we present to them - as copy&paste then modify is a common learning meme.

that said - should I add support for all the date formats go has? and then add things like yesterday, Last Month, oh dear, where do i stop :)

rebased

ping @crosbymichael

Docs LGTM
Thanks for the rebase!

@vieux if the code still looks good to you, please merge.

@SvenDowideit Please run gofmt on your files

@creack rebased and go fmt'd - sorry,

LGTM