Skip to content

Keep the sub-second precision Rails renders - #18

Closed
Jack97 wants to merge 1 commit into
masterfrom
jr/date-time-precision
Closed

Jack97 wants to merge 1 commit into
masterfrom
jr/date-time-precision

Conversation

@Jack97

@Jack97 Jack97 commented Sep 14, 2026

Copy link
Copy Markdown
Collaborator

Time#iso8601 with no argument emits no decimal places. Rails' render json: emits three (ActiveSupport::JSON::Encoding.time_precision), so every date-time in an application migrating onto openapi_kit changed shape and lost precision.

master  "2026-09-14T17:05:03.250Z"
before  "2026-09-14T17:05:03Z"
after   "2026-09-14T17:05:03.250Z"

Found while verifying nexus-api's migration byte-for-byte against the old generator — it affected eight properties there. Decimal, uuid, float, integer and string already matched exactly.

A Rails application rendering a Time through `render json:` emits three decimal
places, because ActiveSupport::JSON::Encoding.time_precision defaults to 3. The
codec called Time#iso8601 with no argument, which emits none, so every date-time
in a migrating application's responses silently changed shape and lost precision:

  master  "2026-09-14T17:05:03.250Z"
  before  "2026-09-14T17:05:03Z"

Found migrating nexus-api, where it affected eight properties across wallet
transactions, uploads, the onboarding checklist and vortex assets.
@Jack97

Jack97 commented Sep 14, 2026

Copy link
Copy Markdown
Collaborator Author

Not proceeding — iso8601 without fractional seconds is fine as the gem's output. Recording the difference on the nexus-api migration instead.

@Jack97 Jack97 closed this Sep 14, 2026
@Jack97
Jack97 deleted the jr/date-time-precision branch September 14, 2026 17:23
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.

1 participant