Skip to content

change all time fields to have type time.Time - #190

Merged
jrperritt merged 16 commits into
gophercloud:masterfrom
jrperritt:75
Jan 12, 2017
Merged

jrperritt merged 16 commits into
gophercloud:masterfrom
jrperritt:75

Conversation

@jrperritt

Copy link
Copy Markdown
Contributor

for #75

@jrperritt jrperritt self-assigned this Nov 15, 2016
@coveralls

coveralls commented Nov 15, 2016 •

Copy link
Copy Markdown

Coverage Status

Coverage increased (+0.06%) to 68.86% when pulling ab73268 on jrperritt:75 into d5eda97 on gophercloud:master.

@jtopjian jtopjian mentioned this pull request Nov 20, 2016
@coveralls

coveralls commented Nov 21, 2016 •

Copy link
Copy Markdown

Coverage Status

Coverage decreased (-0.2%) to 68.598% when pulling 298e50d on jrperritt:75 into d5eda97 on gophercloud:master.

@coveralls

coveralls commented Nov 21, 2016 •

Copy link
Copy Markdown

Coverage Status

Coverage decreased (-0.04%) to 68.763% when pulling 152c611 on jrperritt:75 into d5eda97 on gophercloud:master.

@coveralls

coveralls commented Nov 21, 2016 •

Copy link
Copy Markdown

Coverage Status

Coverage increased (+0.06%) to 68.86% when pulling a759dc7 on jrperritt:75 into d5eda97 on gophercloud:master.

@coveralls

coveralls commented Nov 22, 2016 •

Copy link
Copy Markdown

Coverage Status

Coverage increased (+0.2%) to 68.987% when pulling ffa15cc on jrperritt:75 into d5eda97 on gophercloud:master.

@jrperritt jrperritt changed the title [wip] change all time fields to have type time.Time change all time fields to have type time.Time Nov 22, 2016
@jrperritt

Copy link
Copy Markdown
Contributor Author

I think this addresses most (if not all) of the custom time formats. I'll leave it open until Wednesday if anyone wants to review it.

@jtopjian

Copy link
Copy Markdown
Contributor

I have a few small questions:

It looks like structures with timestamps get declared as time.time, but they should be processed through an UnmarshalJSON method where they are treated as a date format declared in the main gophercloud package. At the end of the method they are changed into time.Time. Is that explaining the process correctly?

It also looks like p is now the standard name that should be used in the struct created in UnmarshalJSON

Should these two points be detailed in the style guide? Even more, it looks like UnmarshalJSON is becoming more of a common step in processing results. Should a note about it be mentioned?

@jrperritt

Copy link
Copy Markdown
Contributor Author

Is that explaining the process correctly?

Yes

It also looks like p is now the standard name that should be used in the struct created in UnmarshalJSON

Thank you for pointing it out. That needs to be changed; r should be the receiver and s the struct.

Should these two points be detailed in the style guide?

The second is a mistake on my part that I'll correct today. I don't think the first is a matter of style, but one of necessity: for the time.Times that are handled in the UnmarshalJSON methods, Go doesn't inherently know how to handle them.

Should a note about it be mentioned?

Here again I don't think this is a matter of style; UnmarshalJSON should only be used out of necessity, such as for a non-built-in type or a variable (read: non-deterministic) type.

However, regardless of where it ends up, I do agree it would be worthwhile to document the process of handling time.Time fields. It could probably go with the yet-to-be-written documentation for using ProviderClient.HTTPClient (#96).

@coveralls

coveralls commented Nov 22, 2016 •

Copy link
Copy Markdown

Coverage Status

Coverage increased (+0.2%) to 68.97% when pulling 24968cb on jrperritt:75 into d5eda97 on gophercloud:master.

type tmp Volume
var s struct {
tmp
CreatedAt gophercloud.JSONRFC3339MilliNoZ `json:"created_at"`

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is probably a silly question but why are we using gophercloud.JSONRFC3339MilliNoZ for CreatedAt and UpdatedAt? As far as I can tell these fields are ISO8601 timestamps and so can contain a "Z". If we set the type to be JSONRFC3339MilliNoZ, json.Unmarshall will error out when processing a date such as "2017-01-04T16:09:33.860887324Z", which should, by my reading, of the specs should be valid.

There's no special marshalling for the CreatedAt and UpdatedAt fields in the images.Image structure yet the openstack API documentation for these fields seems to be identical to documentation for their counterparts in volumes.Volume. Could we perhaps just delete this function and update the tags instead?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see. If we use a time.Time here, we will be unable to process dates that do not contain timezone information, which are also valid ISO8601 dates. However, the current code won't handle those dates properly either. It won't return an error when Unmarshalling but the dates will almost always be interpreted incorrectly, unless both client and server are in the UK or Ireland and it's deep midwinter. ISO8601 dates without timezone information are in local time but time.Parse interprets such date strings as being in UTC. I think the following code would do the correct thing in all cases:

	t, err := time.Parse(time.RFC3339, s)
	if err != nil {
		t, err = time.ParseInLocation("2006-01-02T15:04:05", s, time.Local)
	}

Perhaps the best thing to do would be to create a new goperhcloud time type that uses the above code in its UnmarshalText method.

@markdryan

Copy link
Copy Markdown

I was just wondering when this PR will be merged? We're using gophercloud in https://github.com/01org/ciao but cannot update our vendored version of this package due to issues with the way times are currently handled, e.g., Image.UpdateAt is currently mandatory and "2017-01-04T16:09:33.860887324Z" is not currently accepted as a valid value for Volume.CreatedAt. Looking at the code this PR will fix most of our issues (all if we drop the custom Unmarshalling for volumes.Volume). Is there a plan to merge it any time soon?

@coveralls

coveralls commented Jan 12, 2017 •

Copy link
Copy Markdown

Coverage Status

Coverage increased (+0.2%) to 69.249% when pulling 202cec9 on jrperritt:75 into 8baf47a on gophercloud:master.

@jrperritt
jrperritt merged commit 98d0162 into gophercloud:master Jan 12, 2017
@jrperritt
jrperritt deleted the 75 branch January 12, 2017 20:24
@jtopjian jtopjian mentioned this pull request Feb 23, 2017
cardoe pushed a commit to cardoe/gophercloud that referenced this pull request Aug 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants