Description
The following error is encountered when running tests for the client:
https://circleci.com/gh/grokify/openapi-generator/91#tests/containers/1
=== RUN TestPlaceOrder
--- FAIL: TestPlaceOrder (0.02s)
store_api_test.go:23: Error while placing order
store_api_test.go:24: parsing time ""2018-10-29T21:02:19.201+0000"" as ""2006-01-02T15:04:05Z07:00"": cannot parse "+0000"" as "Z07:00"
Of note, the date-time value that parsing is being attempted for has an offset that is invalid in RFC 3339 format, namely, the UTC offset is +0000 and does not have a colon (:) which is required by RFC 3339.
The Petstore OpenAPI 2.0 spec shows that the OpenAPI type date-time is used:
|
Order: |
|
title: Pet Order |
|
description: An order for a pets from the pet store |
|
type: object |
|
properties: |
|
id: |
|
type: integer |
|
format: int64 |
|
petId: |
|
type: integer |
|
format: int64 |
|
quantity: |
|
type: integer |
|
format: int32 |
|
shipDate: |
|
type: string |
|
format: date-time |
Both OpenAPI 2.0 and 3.0 require RFC 3339 format date-time:
RFC 3339 requires a colon:
time-numoffset = ("+" / "-") time-hour ":" time-minute
https://tools.ietf.org/html/rfc3339#section-5.6
Of note, a +0000 offset without a colon is a valid ISO 8601 date-time offset / timezone designator, but ISO 8601 is not used by OpenAPI spec. Here are the formats for ISO 8601.
<time>Z
<time>±hh:mm
<time>±hhmm
<time>±hh
https://en.wikipedia.org/wiki/ISO_8601
openapi-generator version
master: 8507916
OpenAPI declaration file content or url
https://github.com/OpenAPITools/openapi-generator/blob/8507916d569a8614286708d45a3cbae20e4da6f2/modules/openapi-generator/src/test/resources/2_0/petstore.yaml
Command line used for generation
$ git clone https://github.com/OpenAPITools/openapi-generator
$ cd openapi-generator
$ mvn clean package
$ bin/go-petstore.sh
Steps to reproduce
Run Go tests locally or on CI:
$ mvn verify -f samples/client/petstore/go
Related issues/PRs
Encountered here:
#1291
Suggest a fix/enhancement
This appears to be a server issue. If so, have the server return a RFC 3339 compliant date-time format value like either of the following:
2018-10-29T21:02:19.201+00:00
2018-10-29T21:02:19.201Z
Description
The following error is encountered when running tests for the client:
https://circleci.com/gh/grokify/openapi-generator/91#tests/containers/1
Of note, the
date-timevalue that parsing is being attempted for has an offset that is invalid in RFC 3339 format, namely, the UTC offset is+0000and does not have a colon (:) which is required by RFC 3339.The Petstore OpenAPI 2.0 spec shows that the OpenAPI type
date-timeis used:openapi-generator/modules/openapi-generator/src/test/resources/2_0/petstore.yaml
Lines 566 to 582 in 8507916
Both OpenAPI 2.0 and 3.0 require RFC 3339 format
date-time:RFC 3339 requires a colon:
https://tools.ietf.org/html/rfc3339#section-5.6
Of note, a
+0000offset without a colon is a valid ISO 8601 date-time offset / timezone designator, but ISO 8601 is not used by OpenAPI spec. Here are the formats for ISO 8601.https://en.wikipedia.org/wiki/ISO_8601
openapi-generator version
master: 8507916
OpenAPI declaration file content or url
https://github.com/OpenAPITools/openapi-generator/blob/8507916d569a8614286708d45a3cbae20e4da6f2/modules/openapi-generator/src/test/resources/2_0/petstore.yaml
Command line used for generation
Steps to reproduce
Run Go tests locally or on CI:
Related issues/PRs
Encountered here:
#1291
Suggest a fix/enhancement
This appears to be a server issue. If so, have the server return a RFC 3339 compliant
date-timeformat value like either of the following:2018-10-29T21:02:19.201+00:002018-10-29T21:02:19.201Z