Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

encoding/json: custom format for time.Duration #4712

Closed
wcn3 opened this issue Jan 26, 2013 · 22 comments

Comments

Projects
None yet
10 participants
@wcn3
Copy link

commented Jan 26, 2013

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

This comment has been minimized.

Copy link
Author

commented Jan 28, 2013

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

This comment has been minimized.

Copy link
Author

commented Jan 28, 2013

Comment 2:

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

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2013

Comment 3:

Not for Go 1.1.

Labels changed: removed go1.1.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2013

Comment 4:

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

Status changed to Thinking.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 25, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2013

Comment 6:

Labels changed: added feature.

@robpike

This comment has been minimized.

Copy link
Contributor

commented Aug 19, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2013

Comment 8:

Labels changed: removed go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2013

Comment 9:

Labels changed: added go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2013

Comment 10:

Labels changed: removed feature.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 11:

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

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 12:

Labels changed: added repo-main.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@thatguystone

This comment has been minimized.

Copy link

commented Jul 27, 2015

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 comment has been minimized.

Copy link

commented Jun 23, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Feb 17, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Feb 17, 2017

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.

@rsc rsc closed this Feb 17, 2017

@dlsniper

This comment has been minimized.

Copy link
Contributor

commented Feb 17, 2017

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

@bradfitz

This comment has been minimized.

Copy link
Member

commented Feb 17, 2017

Everything will be considered anew for any Go 2.

@dlsniper

This comment has been minimized.

Copy link
Contributor

commented Feb 17, 2017

@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

This comment has been minimized.

Copy link
Member

commented Feb 17, 2017

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

@fortytw2

This comment has been minimized.

Copy link

commented Feb 17, 2017

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

This comment has been minimized.

Copy link

commented Dec 5, 2017

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.

@golang golang locked and limited conversation to collaborators Dec 5, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.