fix: normalize SDK timestamps to UTC - #224
Conversation
posthog-php Compliance ReportDate: 2026-08-14 11:47:45 UTC ✅ All Tests Passed!46/46 tests passed Capture Tests✅ 29/29 tests passed View Details
Feature_Flags Tests✅ 17/17 tests passed View Details
|
|
Reviews (1): Last reviewed commit: "chore: remove changeset" | Re-trigger Greptile |
arnohillen
left a comment
There was a problem hiding this comment.
(created by claude code)
[arno's agent] Verified at 3ddc93a: docs-and-tests-only, the documented formatter already converts offset inputs to the UTC instant (never relabels) with the regression test proving +05:30 to Z conversion under a non-UTC default timezone; CI fully green including 46/46 compliance.
|
(created by claude code) [arno's agent] The checklist still marks 'Added a patch change intent file' but 3ddc93a removed .changeset/calm-owls-drift.md, so the final diff contains no change intent. |
|
(created by claude code) [arno's agent] formatTime treats falsy timestamps (0, 0.0, '') the same as null and substitutes the SDK clock, which the new int|float|string|null docblock does not mention. |
|
@arnohillen Good catch! Fixed in cba068b — integer and float zero timestamps now serialize as the Unix epoch instead of using the SDK clock. The PHPDoc now documents epoch-number, parseable-string, and null/invalid fallback behavior, with regression coverage for both |
|
@arnohillen Fixed in cba068b — restored the patch change intent file so the checklist now matches the PR diff. |
💡 Motivation and Context
The SDK serializes event timestamps in UTC, but the public
capture,identify, andaliasPHPDoc did not describe the accepted timestamp types or the timezone behavior. This makes the contract explicit for both the client and static APIs. Integer and float values represent epoch seconds, parseable strings may include a timezone offset, andnulluses the SDK-generated timestamp. A timestamp with another timezone is serialized as the equivalent UTC instant.This also adds regression coverage for
identifyandalias. The test changes the PHP default timezone toAmerica/Los_Angeles, sends both calls with2022-05-01T05:30:00+05:30, and verifies that the$identifyand$create_aliasevents both contain2022-05-01T00:00:00+00:00.💚 How did you test it?
vendor/bin/phpunit --bootstrap vendor/autoload.php --configuration phpunit.xml --no-coverage --filter testIdentifyAndAliasTimestampsAreFormattedInUtc test/PostHogTest.phpvendor/bin/phpunit --bootstrap vendor/autoload.php --configuration phpunit.xml --no-coverage test/- 451 tests and 3,830 assertions passed.composer validate --no-check-publishcomposer run api:checkvendor/bin/phpcs --standard=phpcs.xml lib/Client.php lib/PostHog.php test/PostHogTest.phpreported no errors. It still exits with existing warnings on unchanged lines.📝 Checklist
If releasing new changes
🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Pi's worker agent helped reconcile the change with the latest
main, run validation and autoreview, and prepare this draft PR. A public session link is not available from this environment. The newly landed timestamp formatter was kept unchanged, while this PR retains the missing public API documentation and focusedidentifyandaliasregression coverage.