🐛 Source Braintre:: Adds timezone to timestamp in braintree connector

[AGPapa]

What

The incremental sync for the braintree connector misses newly created records, which I believe is a timezone issue. I think that airbyte is sending the "stream interval start time" as a UTC timestamp but Braintree inteprets it in the local timezone for your account. Testing with the braintree API shows this behavior. If I send a timestamp to the Braintree API without a timezone it interprets it in Eastern time, but if I add +00 it will interpret that as a UTC timestamp.

This means that the incremental sync misses records when in a timezone behind UTC (like North America). There wouldn't be missing data for timezones in Europe that are ahead of UTC, since they would pick up more records than they should and de-dup them.

How

To fix this I formatted the timestamp to include the timezone. After this change the Braintree API interprets it correctly.

Review guide

1. airbyte-integrations/connectors/source-braintree/source_braintree/manifest.yaml

User Impact

Users in timezones behind UTC will no longer drop records during incremental syncs. Users in timezones ahead of UTC should see no changes.

Can this PR be safely reverted and rolled back?

• YES 💚
• NO ❌

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
airbyte-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 20, 2024 5:53am

[AGPapa]

For more detail on how Braintree treats timestamps -

This code returns zero rows.

While this code returns data.

The records in my system were created after 2300 UTC, but before 2300 EDT. I believe Braintree is using the timezone that I configured for my sandbox as the default timezone for these timestamps, however it respects the timestamp in the API call if one is present.

Here are the results of syncs on the transaction table before and after these changes:

I ran a full sync, created a transaction in Braintree and then ran an incremental sync. You can see that the incremental sync did not find the new record.

Here I did the same thing (full sync / create transaction / incremental sync) but after the code changes were applied. This picked up the new record.

[natikgadzhi]

Looks good! State format is the same, change is in sending over to API, so it's backwards-compatible.