fix: rely on naive datetime for sqlalchemy

[WilliamBergamin]

Summary

Changes from #1798 resulted in #1832

Some databases like PostgresSQL support timezone aware datetime objects, the current sqlalchemy interface does not support datetime aware object resulting in the following error

sqlalchemy.exc.DBAPIError: (sqlalchemy.dialects.postgresql.asyncpg.Error) <class 'asyncpg.exceptions.DataError'>: invalid input for query argument $3: datetime.datetime(2026, 2, 13, 23, 57, 0... (can't subtract offset-naive and offset-aware datetimes)
[SQL: SELECT slackbot.slack_installations.id 
FROM slackbot.slack_installations 
WHERE slackbot.slack_installations.client_id = $1::VARCHAR AND slackbot.slack_installations.enterprise_id IS NULL AND slackbot.slack_installations.team_id = $2::VARCHAR AND slackbot.slack_installations.installed_at = $3::TIMESTAMP WITHOUT TIME ZONE 
 LIMIT $4::INTEGER]

In order to maintain backward compatibility these changes allow the SDK to support naive datetime objects

Testing

The new integration tests should validate that the changes work with postgreSQL

Category

• slack_sdk.web.WebClient (sync/async) (Web API client)
• slack_sdk.webhook.WebhookClient (sync/async) (Incoming Webhook, response_url sender)
• slack_sdk.socket_mode (Socket Mode client)
• slack_sdk.signature (Request Signature Verifier)
• slack_sdk.oauth (OAuth Flow Utilities)
• slack_sdk.models (UI component builders)
• slack_sdk.scim (SCIM API client)
• slack_sdk.audit_logs (Audit Logs API client)
• slack_sdk.rtm_v2 (RTM client)
• /docs (Documents)
• /tutorial (PythOnBoardingBot tutorial)
• tests/integration_tests (Automated tests for this library)

Requirements

• I've read and understood the Contributing Guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.
• I've run python3 -m venv .venv && source .venv/bin/activate && ./scripts/run_validation.sh after making the changes.

[codecov]

Codecov Report

❌ Patch coverage is 96.15385% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 83.98%. Comparing base (8b0bd0b) to head (7aa92b5).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
slack_sdk/oauth/sqlalchemy_utils/__init__.py	87.50%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1833      +/-   ##
==========================================
+ Coverage   83.96%   83.98%   +0.01%     
==========================================
  Files         116      117       +1     
  Lines       13221    13243      +22     
==========================================
+ Hits        11101    11122      +21     
- Misses       2120     2121       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[WilliamBergamin]

This new job spins up a postgrrrresql db that can then be used to run our unit tests against, it should prevent this type of issue from coming up again 🚀

I tried adding mysql as well but it was failing, I'll it to my TODOs as a follow up PR

[vegeris]

So we've been converting datetimes into UTC but they were interpreted as local times by some databases because the datetime object didn't include the timezone info, so now we have to maintain that behaviour until the next major version, IIUC?

Changes LGTM!

[WilliamBergamin]

So we've been converting datetimes into UTC but they were interpreted as local times by some databases because the datetime object didn't include the timezone info, so now we have to maintain that behaviour until the next major version, IIUC?

@vegeris yess exactly!

[zimeg]

@WilliamBergamin LGTM and thanks for diving into these edges so much 🤖

Let's continue to support UTC for time internals! ⌛ ✨

[zimeg]

🪬 question(non-blocking): Should we check that tzinfo is UTC before removing it? Or converting this first? I haven't explored SQLAlchemy enough but timezones confuse me sincere...

[WilliamBergamin]

So when the tzinfo is not provided SQLAlchemy sets the type as "datetime timezone unaware" and uses utc as the default

If we set tzinfo=utc then SQLAlchemy sets the type as "datetime timezone aware" which creates a breaking change with POSTGRESQL