fix: route timestamps through PostHogDateProvider

[ioannisj]

💡 Motivation and Context

context: https://posthog.slack.com/archives/C03PB072FMJ/p1773659157410299?thread_ts=1773418296.005459&cid=C03PB072FMJ

💚 How did you test it?

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change or entry added to the changelog.

If releasing new changes

• Ran pnpm changeset to generate a changeset file
• Added the "release" label to the PR to indicate we're publishing new versions for the affected packages

[github-actions]

posthog-android Compliance Report

Date: 2026-03-16 13:00:08 UTC
Duration: 147406ms

⚠️ Some Tests Failed

28/29 tests passed, 1 failed

---

Capture Tests

⚠️ 28/29 tests passed, 1 failed

View Details

Test	Status	Duration
Format Validation.Event Has Required Fields	✅	2372ms
Format Validation.Event Has Uuid	✅	2044ms
Format Validation.Event Has Lib Properties	✅	2030ms
Format Validation.Distinct Id Is String	✅	2041ms
Format Validation.Token Is Present	✅	2025ms
Format Validation.Custom Properties Preserved	✅	2032ms
Format Validation.Event Has Timestamp	✅	2024ms
Retry Behavior.Retries On 503	✅	7028ms
Retry Behavior.Does Not Retry On 400	✅	4041ms
Retry Behavior.Does Not Retry On 401	✅	4034ms
Retry Behavior.Respects Retry After Header	✅	7039ms
Retry Behavior.Implements Backoff	✅	17030ms
Retry Behavior.Retries On 500	✅	7039ms
Retry Behavior.Retries On 502	✅	7034ms
Retry Behavior.Retries On 504	✅	7030ms
Retry Behavior.Max Retries Respected	✅	17039ms
Deduplication.Generates Unique Uuids	✅	2062ms
Deduplication.Preserves Uuid On Retry	✅	7031ms
Deduplication.Preserves Uuid And Timestamp On Retry	✅	12039ms
Deduplication.Preserves Uuid And Timestamp On Batch Retry	✅	7042ms
Deduplication.No Duplicate Events In Batch	✅	2032ms
Deduplication.Different Events Have Different Uuids	✅	2029ms
Compression.Sends Gzip When Enabled	✅	2023ms
Batch Format.Uses Proper Batch Structure	✅	2028ms
Batch Format.Flush With No Events Sends Nothing	✅	2020ms
Batch Format.Multiple Events Batched Together	✅	2047ms
Error Handling.Does Not Retry On 403	✅	4031ms
Error Handling.Does Not Retry On 413	❌	4026ms
Error Handling.Retries On 408	✅	7030ms

Failures

error_handling.does_not_retry_on_413

Expected 1 requests, got 2

[ioannisj]

PostHogEvent still uses Date() in the constructor. This is used mainly in tests, but could also default to incorrect date when used for example inside beforeSend hooks to contructor a posthog event.

Not sure how to best handle this though, maybe through the newly added TimeBasedEpochGenerator.customTimeProvider which is set/unset from posthog intance? Open to suggestions

[marandaneto]

i think generate() could take the provider or even the timestamp as a param so its easier to test/debug and no need to use a lambda function?

[ioannisj]

yeah, that would be cleaner if all caller paths have access to the config. will check

[ioannisj]

Looks like this is used in a couple of places were we don't have a config object

• PostHogEvent constructor. We could just pass uuid from buildEvent() so this would be easy to fix
• PostHogSessionManger. This is a singleton and we'll need to pass time on startSession() call. This would need changes in rn plugin as well, or if we want to avoid that, we do this dance of setting/unsetting the provider/config like we do with TimeBasedEpochGenerator anw.

So I would say it would be easier for this to stay as-is. wdyt?

[marandaneto]

wdyt about #463 ?
very similar but earlier and we dont to change anything in the posthog class
your call here to keep yours

[marandaneto]

if you do this, then you dont need that

[marandaneto]

but could also default to incorrect date when used for example inside beforeSend hooks to contructor a posthog event.

as long as the sdk is correct when we create the event, all is fine, if they create their own instance, they need to make sure to set the correct data right, otherwise they could just either mutate or do .copy/.clone with the current instance which would keep most of the data the same

[marandaneto]

i'd rather keep just one, and non nullable, that can be replaced with a setter instead of having both custom + default and one nullable

[marandaneto]

left a suggestion but not a blocker, LGTM