Zero time.Time

[Mikhail Strebkov]

I'm porting my small project from r60.3 to weekly-2012-02-07. I have a function 

 

func parseTime(format, value string) (*time.Time, os.Error) {

    time, err := time.Parse(format, strings.TrimSpace(value))

    if err != nil {

        return nil, err

    }

    return time, nil

}

After using "go fix" it became

 

func parseTime(format, value string) (time.Time, error) {

    time, err := time.Parse(format, strings.TrimSpace(value))

    if err != nil {

        return nil, err

    }

    return time, nil

}

From documentation: "Programs using times should typically store and pass them as values, not pointers". OK, now I need to change " return nil, err" to something like "return time.ZeroTime, err". There is IsZero() function for time.Time receiver but there are no ZeroTime constant. How can I create zero time struct? Or I miss something?

[David Symonds]

time.Time{}

[Mikhail Strebkov]

It was my first move, but "go build" prints this:

.\parse.go:13: time.Time undefined (type time.Time has no field or method Time)

[chris dollin]

Why not bypass the issue, avoid any testing, and just return `time, err`?

Chris

--
Chris "allusive" Dollin

[David Symonds]

On Feb 12, 2012 12:20 AM, "Mikhail Strebkov" <stre...@gmail.com> wrote:

> It was my first move, but "go build" prints this:
>>
>> .\parse.go:13: time.Time undefined (type time.Time has no field or method Time)

That can't be right. What's the whole code that yields that error?

Dave.

[Mikhail Strebkov]

Sorry, my mistake. The name of the local variable is the same as the "time" package. Fixed it and now time.Time{} works as it should.

[Mikhail Strebkov]

You're right! Changed it to

func parseTime(format, value string) (time.Time, error) {

    return time.Parse(format, strings.TrimSpace(value))

}

[Roberto Costumero Moreno]

I am not very fond of one-line functions that encapsulate a funcionality, because you overload the execution with all the function calls in the stack.

Is there any reason why you're leaving the function as it is now and not using time.Parse wherever you use parseTime?

[chris dollin]

On 11 February 2012 14:54, Roberto Costumero Moreno

<rob...@costumero.es> wrote:
> I am not very fond of one-line functions that encapsulate a funcionality,
> because you overload the execution with all the function calls in the stack.

Inlining.

[Mikhail Strebkov]

Me too. There is a reason but not very strong -  there are other functions "parse<Something>" (longer than one line) in my parse.go file and the main program code reads better if I leave parseTime as it is now.