Time
One tool that answers "what is the date" and "what date is next Friday" — so an agent computes dates instead of guessing them.
Models are unreliable about the current date and worse at arithmetic on it. The time tool gives an agent a real answer.
get_datetime
One tool. It returns a 10-digit Unix timestamp for the current moment, or for a date described relative to it.
Called with no arguments it answers "now". Add arguments to move from there.
| Argument | Type | Does |
|---|---|---|
timezone | string | IANA name — UTC, America/New_York, Asia/Kolkata. Defaults to UTC |
days | number | Add N days |
weeks | number | Add N weeks |
months | number | Add N months |
weekday | string | Target weekday — monday … sunday |
date | number | Day of month, 1–31 |
month | string | Month name — january … december |
year | number | A specific year, used with month and date |
How the arguments combine
The order matters, and it is the part worth knowing:
weeks+weekday— the week offset is applied first, then the weekday is found in that week.{weeks: 1, weekday: "friday"}is next week's Friday.months+date— the month offset is applied first, then the day is taken from that month.{months: 1, date: 16}is the 16th of next month.monthalone — goes to that month in the current year, or next year if it has already passed.
In a system prompt
Agents do not always think to check the date. Tell them:
At the start of each conversation, call get_datetime to learn the current
date before answering anything time-related. Never guess a date.This matters most for agents that write to calendars, file reports by date, or compute deadlines — the failure mode is silent, confidently wrong, and easy to miss in a run log.
Caching
get_datetime is not memoised — an answer that could be reused would defeat the point. Deterministic tools like the parsers are cached; this one is not. See Caching.