[Feature request] - Ability to specify custom DateTime format

[agnivade]

Currently, the DateTime type is hardcoded to receive only time values in RFC3339. It would be nice if we can specify custom time formats. It shouldn't be too hard I think, we just need to pass the specified layout string instead of the constant RFC3339.

[raphael]

Unfortunatly I don't think it's as simple as it sounds, the first issue is the DSL - we'd have to introduce different types which is actually quite a bit of work (all the generators would have to be updated to support them). Another issue is that Swagger only supports RFC3339. Given this my inclination is to keep the DateTime encoding as RFC3339 and use strings for other encodings. There's already support for RFC1123 there - others could be easily added. A final comment that v2 does away completely with the DateTime type in favor of using strings with formats. This simplifies the code generators and makes for a cleaner semantic.

[agnivade]

Hmm Swagger not supporting anything else is indeed an issue. But if you use string with formats, you will still lose the type safety right ? Wouldn't the user have to parse the string into DateTime into his/her own code ?

[raphael]

The generated code does validate the format so you can be certain that the string will parse correctly into a DateTime value or the generated code returned a BadRequest to the client.

[agnivade]

Can you give an example of how that will be ? I was thinking of something like this -

Attribute("date", String, "Date of the event", func() {
	Format("2015/02/03")
})

So, wouldn't the date parameter be of type string ?

[raphael]

The format would have to be a set list - not an arbitrary string like you have. So FormatRFC3339 or FormatRFC1123 etc. constants that are defined in the goa design package (thinking v2 here).
The generated server code then validates the format when decoding a request and the generated client code also validates when decoding a response. So you can safely call time.Parse(time.RFC3399, value) and be sure that there won't be any error.

[agnivade]

Ah, I got you now. My point was slightly different. Even if the server validates the format, I would have to parse the string to a datetime anyways. That was my gripe. I don't want that. I would want Goa to directly give me a datetime type. Which is the whole reason for me to use Goa. Otherwise I can do a strconv.ParseInt to get an int too.

It seems that in v2, you are going away with the datetime type altogether. I would liked for datetime to remain, but I can understand that problems you are facing.

Feel free to take a call on this (put it on the backburner or close the issue). But I would still like to be able to specify a custom format and still directly get a datetime object.

Thanks !

[raphael]

I was expecting to get a push back on dropping the DateTime type. It's just a lot of work and potential for bugs but I understand it's also convenient. I'll leave this issue opened and welcome PRs to add the type to v2.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[raff-wakflo]

Sorry for reopening this, but could this be reconsidered in v3. I mean the DateTime support again I understand the complexities but is this permanent won't fix issue?

[raphael]

Reopening the issue. I'd welcome a PR that adds DateTime as a native type in Goa, the encoding could follow the same pattern as Google's Timestamp protobuf type: a structure containing two fields, one for seconds (int64) and the other for nanoseconds (int32). Fair warning: this is a fairly involved task that would have to change code in many places.