[FEATURE] Inconsistent timestamp formats in episodic memories

[Joker-tian-pei]

Hello team,

I noticed that the timestamps recorded in episodic_memories currently have quite inconsistent formats. Here are some examples from the data:

• 2026年1月22日11:25:33+00:00
• 2026年1月22日11:25:33+00:00:00
• 2026年1月22日11:27
• 2026年1月22日11:27:55 UTC
• 2026年1月23日02:19:25 UTC
• 2026年1月23日02:19:25+00:00
• 2026年1月23日 （周五） 上午10:07

These variations include different problems such as:

• Chinese vs English date expressions
• With/without weekday (周五)
• With/without timezone (UTC / +00:00 / +00:00:00)
• Different precision levels (missing seconds, etc.)
• Mixing full datetime and partial time

This inconsistency makes it more difficult and error-prone for later parsing, sorting, filtering, and time-based operations.

From a quick look at the code, it seems the format is mainly controlled by the prompt in episode_mem_prompts.py.

Suggestion

We could strengthen the prompt to enforce a single, standardized format, for example strict ISO 8601:

• Recommended format: 2026-01-23T02:19:25Z
  or 2026-01-23T10:07:00+08:00

Example instruction we could add to the prompt:
"Always output timestamps in strict ISO 8601 format with timezone, e.g. 2026-01-23T02:19:25Z. Do not use Chinese characters, weekdays, or any other non-standard format."

Questions / Next steps

1. Would updating the prompt in episode_mem_prompts.py to enforce consistent ISO 8601 format be a safe and effective solution?
2. Could this change potentially break any existing code that is already tolerant of multiple formats?
3. Should we consider adding a lightweight normalization function as a fallback (in case the model sometimes ignores the prompt)?

Thank you for your time!

[youziiWu]

Hi there,

Thx a lot for your advice. We'll fix this issue in the upcoming commit.

About your question:

1. Yes, it's safe.
2. No
3. This is a trade-off, if we have ordered LLM to follow our time format strictly, the fallback logic would be weird because of the LLM's instability.