fix(source-jira): use unix time as milliseconds when filtering the cursor field via jql

[ryanahall]

…s due to timezone conversions

What

According to https://support.atlassian.com/jira-software-cloud/docs/jql-fields/#Updated, date times are relative to the current configured timezone. In some cases (i.e. using a personal access token), the currently configured timezone may not be UTC.

When streams use the jira advanced search api and request records using JQL (https://support.atlassian.com/jira-service-management-cloud/docs/use-advanced-search-with-jira-query-language-jql/), this cursor value is formatted without a timezone as seen below:

        compare_date = self.get_starting_point(stream_state)
        if compare_date:
            compare_date = compare_date.strftime("%Y/%m/%d %H:%M")
            return f"{self.cursor_field} >= '{compare_date}'"

In our case, we've noticed that the issues stream for jira returns records with an updated field value (the cursor field) formatted as UTC. Subsequent syncs will use this value, truncate the timezone (which is UTC), and pass it along to jira. When the session has a timezone that has a negative UTC offset, this results in data being skipped. When the session has a timezone with a positive UTC offset, data is unnecessarily emitted.

For example, an initial sync may return it's final issue record with a cursor of 2024-11-06 12:00:00.000+0000 representing noon UTC time. The next sync will query using jql with the following filter: updated >= '2024-11-06 12:00:00'. If the session's timezone is America/Los_Angeles, then this filters records with an updated time that is greater than or equal to 2024-11-06 20:00:00.000+0000 due to the UTC offset. Any records updated between 12 and 20 UTC time are skipped.

How

According to https://support.atlassian.com/jira-software-cloud/docs/jql-fields/#Updated, the jira jql api supports epoch values when filtering against the updated field amongst other timestamp fields. Notably, they mention that if you omit the quote-marks, the number you supply will be interpreted as milliseconds after epoch (1970-1-1).

This change modifies jql_compare_date to append a filter of {self.cursor_field} >= {compare_date_epoch}, where compare_date_epoch represents the epoch value in milliseconds of the current datetime value.

Review guide

User Impact

If the session is already configured with a UTC timezone, there's no change. For sessions with a timezone offset from UTC, they should see more consistent record updates for incremental streams.

Can this PR be safely reverted and rolled back?

• YES 💚
• NO ❌

[vercel]

@ryanahall is attempting to deploy a commit to the Airbyte Growth Team on Vercel.

A member of the Team first needs to authorize it.

[CLAassistant]

All committers have signed the CLA.