Do not input private or sensitive data. View Qlik Privacy & Cookie Policy.
Skip to main content

Announcements
Write Table now available in Qlik Cloud Analytics: Read Blog
cancel
Showing results for 
Search instead for 
Did you mean: 
Anonymous
Not applicable

header__timestamp in change tables off by 2 months

I have just started to type 2 data in our warehouse and am starting to interrogate the change tables and their values.   I notice that starting in about mid October 2021  the header__transaction date is about 2 months ahead of the varchar value stored in header__change_seq.   This is consistant across all our tasks that span different SQL Server Sources.   Prior to mid October 2021 the header__change_seq value and header__timestamp were the same.  So today (2/16/2022) I have change records being added to  change tables with a header__timestamp of "2022-04-07 hh:mi:ss.xxx".  Has anyone seen this and is this something with Postgres?

1 Solution

Accepted Solutions
shashi_holla
Support
Support

Hi Brian,

Are you on Replicate version 7.0 because this issue was reported earlier in Replicate version 7.0.0.514 or prior and was fixed in version 7.0.0.555. 

Thanks,

View solution in original post

6 Replies
shashi_holla
Support
Support

Hi Brian,

Are you on Replicate version 7.0 because this issue was reported earlier in Replicate version 7.0.0.514 or prior and was fixed in version 7.0.0.555. 

Thanks,

Anonymous
Not applicable
Author

Thanks, we are on 7.0.0.470. so we will get up to date ASAP.

Anonymous
Not applicable
Author

Upgrading solved the issue.

robertde
Contributor
Contributor

Thanks for pointing this out. A consistent 2-month offset in header__timestamp starting mid-Oct 2021 likely indicates an issue during ingestion—possibly a timezone, ETL, or transformation change. Postgres itself wouldn’t shift timestamps like this.

Might be worth tracing values from source to warehouse to pinpoint where the drift starts.

Debugging this isn’t exactly Toca Kitchen 2, but we’ll get it sorted!

jackevan
Contributor
Contributor

Sounds like a timezone or ETL issue—Postgres might be interpreting timestamps differently than SQL Server. Check your pipeline settings and server timezones.

Just like with CapCut Pro APK, using the wrong source can lead to unexpected results. Always double-check configurations!

Michaell
Contributor
Contributor

That 2-month offset sounds like a timezone or ingestion issue — especially if it's consistent across different SQL Server sources. It might be how Postgres is handling timestamps (e.g. with/without time zone). Check your ETL process and time zone settings on both ends.

I’ve seen similar timestamp mismatches before while syncing data for tests (like with Avatar World APK Unlocked All) — usually tied to timezone configs.