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

Documentation for timestamp unclear on "whole seconds" JSON formatting #670

Closed
jskeet opened this issue Jul 31, 2015 · 1 comment
Closed

Documentation for timestamp unclear on "whole seconds" JSON formatting #670

jskeet opened this issue Jul 31, 2015 · 1 comment
Assignees
Labels

Comments

@jskeet
Copy link
Contributor

@jskeet jskeet commented Jul 31, 2015

The JSON documentation for Timestamp states:

Uses RFC 3339, where generated output will always be Z-normalized and uses 3, 6 or 9 fractional digits.

It's unclear whether the Unix epoch (for example) should be formatted as 1970-01-01T00:00:00Z or 1970-01-01T00:00:00.000Z. Looking at the C++ code, it seems like it's the former - but that should be clarified in the documentation.

@xfxyjwf
Copy link
Contributor

@xfxyjwf xfxyjwf commented Mar 16, 2017

Now it has been updated to:

Uses RFC 3339, where generated output will always be Z-normalized and uses 0, 3, 6 or 9 fractional digits.

For whole seconds, the fractional parts should be omitted.

@xfxyjwf xfxyjwf closed this Mar 16, 2017
vosst pushed a commit to airmap/protobuf that referenced this issue Oct 17, 2018
…ers#671)

The purego implementation is unable to handle unexported fields since it is
impossible for purego code to mutate such fields without using unsafe.

Also, modify the Makefile to test the purego code paths.

Fixes protocolbuffers#670
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants