Conversation
When a model's $dateFormat is 'datetime' and the connection's dateFormat['datetime'] mask includes .v/.u (millisecond/microsecond precision), auto-generated created_at/updated_at timestamps always rendered .000000 instead of the real sub-second value. setDate() converted the current Time instance to a Unix timestamp integer before formatting it, which discards anything below whole-second precision. timeToDate() already formats a Time object directly and retains sub-second precision, but nothing routed the no-explicit-date case through it. Fixes codeigniter4#10540
5 tasks
|
Hi there, wakqasahmed! 👋 Thank you for sending this PR! We expect the following in all Pull Requests (PRs).
Important We expect all code changes or bug-fixes to be accompanied by one or more tests added to our test suite to prove the code works. If pull requests do not comply with the above, they will likely be closed. Since we are a team of volunteers, we don't have any more time to work See https://github.com/codeigniter4/CodeIgniter4/blob/develop/contributing/pull_request.md Sincerely, the mergeable bot 🤖 |
michalsn
approved these changes
Sep 17, 2026
datamweb
approved these changes
Sep 17, 2026
TimexPeachtree
approved these changes
Sep 17, 2026
paulbalandan
approved these changes
Sep 18, 2026
BaseModel datetime timestamps
This comment has been minimized.
This comment has been minimized.
…ate-microseconds-v2 # Conflicts: # user_guide_src/source/changelogs/v4.7.5.rst
Member
|
Thank you @wakqasahmed, and congrats on your first contribution to the project! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces #10541, which I can't update in place — the branch there has two commits with the wrong git identity from an earlier session, and this environment blocks both rewriting that history and force-pushing over it, even to my own fork. Same diff, plus the changelog entry @michalsn asked for.
When a model's
$dateFormatis'datetime'and the connection'sdateFormat['datetime']mask includes.v/.u(millisecond/microsecond precision), auto-generated timestamps forcreated_at/updated_atalways rendered.000000instead of the real sub-second value.setDate()converted the currentTimeinstance to a Unix timestamp integer (Time::now()->getTimestamp()) before formatting it, which discards anything below whole-second precision.timeToDate()already formats aTimeobject directly and correctly retains sub-second precision (TimeextendsDateTimeImmutable), but nothing routed the "no explicit date passed" case through it.Changed
setDate()so that when no explicit$userDateis given and the model's format is'datetime', it callstimeToDate(Time::now())instead of going throughintToDate(). The'int'and'date'formats, and the case where an explicit integer timestamp is passed, are unchanged.Added a test in
GeneralModelTestthat pins the current time to a value with microsecond precision and asserts both.vand.uformat masks render correctly, plus the changelog entry inv4.7.5.rst.Fixes #10540