Time are messed up in Chainlit

[asvishnyakov]

Describe the bug

chainlit/backend/chainlit/data/chainlit_data_layer.py

Lines 374 to 377 in 0e863ae

	timestamp = await self.get_current_timestamp()
	created_at = step_dict.get("createdAt")
	if created_at:
	timestamp = datetime.strptime(created_at, ISO_FORMAT)

Saves in UTC (with Z), but

chainlit/backend/chainlit/data/chainlit_data_layer.py

Line 635 in 0e863ae

createdAt=row["createdAt"].isoformat() if row.get("createdAt") else None,

reads in local time (without Z)

and when system tries to save it again we get exception

2025-09-03 22:00:48 - Task exception was never retrieved
future: <Task finished name='Task-1150' coro=<ChainlitDataLayer.update_step() done, defined at /Users/dmitriy/Documents/GitHub/cookbook/resume-chat/.venv/lib/python3.13/site-packages/chainlit/data/utils.py:10> exception=ValueError("time data '2025-09-04T02:00:42.164000' does not match format '%Y-%m-%dT%H:%M:%S.%fZ'")>
Traceback (most recent call last):
  File "/opt/homebrew/Cellar/python@3.13/3.13.3/Frameworks/Python.framework/Versions/3.13/lib/python3.13/asyncio/tasks.py", line 304, in __step_run_and_handle_result
    result = coro.send(None)
  File "/Users/dmitriy/Documents/GitHub/cookbook/resume-chat/.venv/lib/python3.13/site-packages/chainlit/data/utils.py", line 25, in wrapper
    return await method(self, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/dmitriy/Documents/GitHub/cookbook/resume-chat/.venv/lib/python3.13/site-packages/chainlit/data/chainlit_data_layer.py", line 388, in update_step
    await self.create_step(step_dict)
  File "/Users/dmitriy/Documents/GitHub/cookbook/resume-chat/.venv/lib/python3.13/site-packages/chainlit/data/utils.py", line 25, in wrapper
    return await method(self, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/dmitriy/Documents/GitHub/cookbook/resume-chat/.venv/lib/python3.13/site-packages/chainlit/data/chainlit_data_layer.py", line 368, in create_step
    timestamp = datetime.strptime(created_at, ISO_FORMAT)
  File "/opt/homebrew/Cellar/python@3.13/3.13.3/Frameworks/Python.framework/Versions/3.13/lib/python3.13/_strptime.py", line 674, in _strptime_datetime
    tt, fraction, gmtoff_fraction = _strptime(data_string, format)
                                    ~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Cellar/python@3.13/3.13.3/Frameworks/Python.framework/Versions/3.13/lib/python3.13/_strptime.py", line 453, in _strptime
    raise ValueError("time data %r does not match format %r" %
                     (data_string, format))
ValueError: time data '2025-09-04T02:00:42.164000' does not match format '%Y-%m-%dT%H:%M:%S.%fZ'

when returned back to data layer and it tries to update thread step

To Reproduce
See #2486

Expected behavior
UTC should be saved returned

[dosubot]

This is a known issue: Chainlit's data layer returns datetime strings for created_at without the 'Z' suffix, which indicates UTC. This causes a ValueError when the code tries to parse the string using the format %Y-%m-%dT%H:%M:%S.%fZ, since Python's datetime.isoformat() does not append 'Z' by default. Both DynamoDB and SQLAlchemy return the correct UTC format with the 'Z' suffix, but Chainlit does not, leading to failures when updating thread steps. The expected behavior is that all timestamps should be formatted with the 'Z' suffix to indicate UTC, matching the ISO format used for parsing. This bug is tracked in issue #2491 and issue #2085. The fix is to ensure all timestamps returned by Chainlit's data layer are formatted with the 'Z' suffix.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[asvishnyakov]

Oh wow.

@DmitriyAlergant thanks for dragging me down this rabbit hole.

So basically, timezone handling in Chainlit is completely messed up.

First, there’s the bug described above, which strips the Z from proper UTC time and by so converts it to local time in steps (messages).

Then:

• Messages, steps & callbacks use UTC
• For threads, the Chainlit data layer uses the local server time.
• And the cherry on top: the SQLAlchemy and DynamoDB data layers add a Z to the local server “now” time for threads, effectively creating dates and times in the future.

The "ideal" all-UTC implementation is in #2490. However, since there are no migrations, it would be a breaking change, and I don't know how to resolve that.

@hayescode @sandangel Thoughts?

[hayescode]

@asvishnyakov good find! Everytime I go deep on something I find some pretty extensive tech debt :(

I'm working on #2469 to unify the base shared components used throughout plus the data layers. Things like created_at should be set in one place but as you point out they're set in many places. I'm thinking something like this:

https://github.com/Chainlit/chainlit/blob/feat%2Fsqlmodel/backend%2Fchainlit%2Fmodels%2Fuser.py#L41

I'm also introducing alembic versioned migrations here too so we could migrate everyone automatically this way. My preference would be to wait for this as this will also introduce a breaking change because I plan to delete the other SQL data layers, not add yet another one. dynamoDB will remain, and be updated for the new components (and simplified since pydantic will easily handle the serialization). So sqlmodel and dynamoDB stay. We need to talk about LiteralAI too because I'd like to delete that too. I'm not sure how many people are hosting their own LiteralAI but I'm guessing not many since that's the reason they're bankrupt...

[asvishnyakov]

@hayescode Yeah, I know the universal data layer with migrations is our holy cow - I’ll join as soon as I can. But what do we do before that? :)

Maybe @DmitriyAlergant is right, and it’s better to introduce a flexible parser for now and support this whole zoo. Or maybe it’s not such a big deal, and we should just replace everything with UTC now, even if it messes up users’ thread order for about a day.

What options come to your mind?

[DmitriyAlergant]

I'm very new to the project so should not be making opinions really... From an outside perspective, I would considered
bundlng together a major SQL backend cleanup + untangling timezones mess at the same time (as one, big, somewhat-breaking change); This is where you can standardize of storing utc's in datatabase, maybe even apply time conversions during the migration; etc.

While applying this parsing crutch in the interim.

[DmitriyAlergant]

And sorry for dragging you into this rabbit hole:)