encoding/json: custom format for time.Duration

[wcn3]

Feature request:

JSON struct tags could be enhanced to provide the notion of time units since the parser
currently assumes everything is ns, causing workarounds of the type that may need to get
fixed, as in https://golang.org/cl/7086059

Sample code: http://play.golang.org/p/CZH9ThvhxK

What is the expected output?
&{Access:12345 Refresh:23456 ExpiresIn:1h0m0s ValidIn:1.234us}
2013-01-21 22:37:40.646947673 -0800 PST
2013-01-21 23:37:40.647083585 -0800 PST

What do you see instead?
&{Access:12345 Refresh:23456 ExpiresIn:3.6us ValidIn:1.234us}
2009-11-10 23:00:00 +0000 UTC
2009-11-10 23:00:00.0000036 +0000 UTC

[wcn3]

Comment 1:

Updated proposed syntax in http://play.golang.org/p/LHuEhLVmTt to matchkey-value
encoding used in protobuf struct tags. http://play.golang.org/p/LHuEhLVmTt

[wcn3]

Comment 2:

Updated proposed syntax to match key-value encoding used in protobuf package.
http://play.golang.org/p/LHuEhLVmTt

[rsc]

Comment 3:

Not for Go 1.1.

Labels changed: removed go1.1.

[rsc]

Comment 4:

Labels changed: added priority-later, removed priority-triage.

Status changed to Thinking.

[rsc]

Comment 5:

It is unclear to me whether we can do this.
Go 1.1 programs would not be able to read the Go 1.2 encoding,
although we could make Go 1.2 programs able to read the Go 1.1 encoding.
It's not that encoding/json is assuming nanoseconds, it's that it's treating the
Duration as a simple int64.

Labels changed: added go1.2maybe.

[rsc]

Comment 6:

Labels changed: added feature.

[robpike]

Comment 7:

I don't think we can do this. It won't be in 1.2 in any case.

Labels changed: added go1.3maybe, removed go1.2maybe.

[robpike]

Comment 8:

Labels changed: removed go1.3maybe.

[rsc]

Comment 9:

Labels changed: added go1.3maybe.

[rsc]

Comment 10:

Labels changed: removed feature.

[rsc]

Comment 11:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 12:

Labels changed: added repo-main.

[thatguystone]

Rather than applying struct tags, it might be simpler just to use time.ParseDuration(). For example: http://play.golang.org/p/M7b2LZWQPD

As you'll notice, in the example, it accepts both strings and ints, which preserves backwards compatibility. Of course, this is lacking implementations of MarshalBinary/Text/etc since it's merely an example.

[jblachly]

This bit me tonight in Go 1.6. It is disappointing to think that we are still clinging to compatibility when it is (in my view) more likely that bugs are being introduced due to the lack of implementation of json.Marshaler.

[dlsniper]

I could propose this as an alternative:

type demo struct {
	Field  time.Time     `json:"name,omitempty,layout:Mon Jan _2 15:04:05 2006"`
	Field2 time.Duration `json:"name,omitempty,duration:42s"`
}

[rsc]

If you want a custom duration marshaling, define a type that implements json.Marshaler/json.Unmarshaler. At this point we're not going to change this fundamental detail of the json package.

[dlsniper]

@rsc maybe could be considered for an upcoming major version of Go (2.x) ?

[bradfitz]

Everything will be considered anew for any Go 2.

[dlsniper]

@bradfitz then can this be labeled as such so it doesn't get lost? Yes, I know right now you can just create a new type then carry the transformation around the whole program wherever needed to use the filed as time.Time but this is rather inconvenient.
And in all fairness, this was labeled as Thinking and deprioritized ever since Go 1.1. I could offer a CL for it as it wouldn't break anything in the Go compatibility if so desired but it's frustrating to just have it closed like this.
Thank you.

[bradfitz]

Since it's labeled Thinking, we're good. We'll find it back if/when we think about Go2.

[fortytw2]

The idea for supporting custom time.Time layout in the struct tags like @dlsniper suggested seems a bit out of scope for the original issue, but would be an incredible improvement IMHO - perhaps it's worth discussing it in another issue / proposal?

[hgl]

Ideally the conversion process could be exposed, some thing along the line like this. So it's customizable on how to convert one type to another when decoding/encoding.