Upgrading to 3.40.0 causing token rotation and installation to fail due to installation.installed_at change.

[RubberDuckyToyFactory]

Reproducible in:

The Slack SDK version

slack_bolt==1.23.0
slack_sdk==3.40.0

Python runtime version

Python 3.12.3

OS info

Ubuntu SMP PREEMPT_DYNAMIC Tue Jan 13 16:40:06 UTC 2026

Steps to reproduce:

1. initiate token_rotation or app installation.

Expected result:

Installation data is written to the database

Actual result:

It fails with 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]
[parameters: ('2542883913523.8580429677536', 'T02FYRZSVFD', datetime.datetime(2026, 2, 13, 23, 57, 0, 244741, tzinfo=datetime.timezone.utc), 1)]
(Background on this error at: https://sqlalche.me/e/20/dbapi)

If I downgrade to 3.39.0 it works as expected.

The only recent change I see in the SDK related to this is here,

installed_at on line 195 was changed from
now = datetime.utcfromtimestamp(time.time() + self.expiration_seconds)
to
now = datetime.fromtimestamp(time.time() + self.expiration_seconds, tz=timezone.utc)

The former is returns a naive datetime object, whereas the latter returns a timezone-aware datetime object.

The slack_installations table definition for installed_at is:

                "installed_at",
                DateTime,
                nullable=False,
                default=sqlalchemy.sql.func.now(),
            ),

I am using Postgres v16 for my database and the installed_at field is created with the postgres type timestamp -- it is not timezone aware. So the new timezone aware timestamp from the sdk is where the problem occurs. If this is the case then the only solution would be to downgrade to 3.39.0 or update the slack_installation table definition to support the timezone or update the sdk to return a naive datetime object again.

[RubberDuckyToyFactory]

Alternatively, the table definition could be updated to include the timezone=True flag in the constructor; DateTime(timezone=True). This would create the correct table datatype.