[Feature]: Add datetime to system prompt context

[gazambuja]

Preflight Checklist

• I have searched existing requests and this hasn't been proposed yet
• If this request came from a chat session issue, I included relevant session context and redacted secrets

Problem statement

The model lacks real-time temporal awareness, leading to frequent hallucinations regarding the current date. How can we programmatically include a dynamic 'system_time' variable in the prompt context?

Proposed solution

inject the datetime to the context

Alternatives considered

No response

Category

Other

How important is this to your workflow?

Critical — blocking my use of Moltis

Additional context

No response

Chat session context (if applicable)

[penso]

Agreed.

[gazambuja]

seems that Hooks is the answer. but I still do not make it work...

+++
name = "datetime-injector"
description = "Injects current date and time into every LLM message"
emoji = "🕐"
events = ["MessageSending"]
command = "./handler.sh"
timeout = 2
+++

# Datetime Injector Hook

This hook injects the current local date and time into every message
sent to the LLM, so you always know what time it is on the user's system.

## How it works

1. Subscribes to `MessageSending` event
2. Runs `date` command to get current local time
3. Modifies the message payload to include the datetime context

cat handler.sh

#!/usr/bin/env bash
# handler.sh — injects current datetime into every LLM message

# Read the incoming payload from stdin
payload=$(cat)

# Get current local datetime
current_datetime=$(date "+%Y-%m-%d %H:%M:%S %Z")

# Output the modification action with the datetime in local time
echo "{\"action\":\"modify\",\"data\":{\"content\":\"[System: The user's current local date and time is: $current_datetime]\"}}"

[penso]

I just added the datetime to system prompt in the latest release. I will do a fix for the timezone in another, so it's not the server timezone (when deploying to the cloud) but the user timezone. Let me know if that helps, close the issue if so.

[gazambuja]

The time on the runtime section is not enough to make all LLMs acknowledge that. I made some simple test with for example, Minimax M2.5, and he try to call a tool to get the datetime or even hallucinate.

I think will work a lot better if you add at the end of the prompt (inside the "Guidelines") something like "The current user datetime is {time}."

[penso]

ah yes I did not try on minimax, it's very annoying than models act so differently :(

[gazambuja]

yep... also, add that (change every request) at the end, improve the cache hits on some models

[penso]

The issue I see is everyone has different needs, different expectations while wanting to try to lower the amount of tokens used. I'd like to find a way to make every case by having something dynamic for system prompt data. I'm not sure what form that should take yet.

[gazambuja-gif]

Make it editable and put some variables so everyone can customize if needed?

[penso]

I'm going to do profiles so you can have different system prompt, and I'll also add templates so you can build your own and reuse available variables.

[lee-b]

Adding a timestamp to requests defeats caching (unless you add it to the final message and remove it again each time). It's usually better to just give the bot a tool that it can use to obtain the time, or date, or whatever, as and when needed.

[penso]

Adding a timestamp to requests defeats caching (unless you add it to the final message and remove it again each time). It's usually better to just give the bot a tool that it can use to obtain the time, or date, or whatever, as and when needed.

That actually makes sense, so a date and time tool?

[rio]

I agree. This makes it very painful to run on my local Strix Halo system.

[rio]

to be honest, just stripping off the time and only include the current date would be a huge improvement.