# Retrieve the date and time in a scene **URL:** \ **Category:** Demandes livrées\ **Tags:** feature-core, in-progress\ **Created:** [April 8, 2024, 1:32pm UTC](https://community.gladysassistant.com/t/recuperer-la-date-et-lheure-dans-une-scene/8821 "2024-04-08T13:32:42Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![prohand](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/prohand/32/15713_2.png) [@prohand](https://community.gladysassistant.com/u/prohand)\ **Post date:** [April 8, 2024, 1:32pm UTC](https://community.gladysassistant.com/t/recuperer-la-date-et-lheure-dans-une-scene/8821/1 "2024-04-08T13:32:42Z")
**Feature description** Following this thread: [Récuperer date/heure dans mqtt - #3 par prohand](https://community.gladysassistant.com/t/recuperer-date-heure-dans-mqtt/8819/3) I think it would be nice to be able to retrieve the time locally in a scene and not via an external web service 🙂 ---
**Author:** ![StephaneB](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/stephaneb/32/15443_2.png) [@StephaneB](https://community.gladysassistant.com/u/StephaneB)\ **Post date:** [August 16, 2026, 9:09pm UTC](https://community.gladysassistant.com/t/recuperer-la-date-et-lheure-dans-une-scene/8821/2 "2026-08-16T21:09:44Z")
@pierre-gilles I’m bringing this request back up, which could be included in next week’s updates. I describe a use case: To monitor the startup of my heat pump (it’s new, I want to keep an eye on its operation regularly), I want to be notified every hour of the last startup. A message like « The last startup of the heat pump was 26 minutes ago » I would therefore like to do the following: - Create a virtual MQTT device ‹ last heat pump startup › - In scene A, with the trigger being the heat pump starting, store the current date/time in this MQTT device - In scene B, which triggers every hour, retrieve the current date/time and the ‹ last heat pump startup › date, calculate the difference and send me a message For this, Gladys would need to: - Be able to create a virtual device of type ‹ date and time › - Have a scene action to retrieve the current date and time as a variable, usable in the rest of the scene (perhaps by indicating the expected ‹ precision ›: second, minute, hour, day,… Because for example in my case the minute would suffice, and if Gladys gives me info to the millisecond, my message will be unnecessarily precise) - Define how a ‹ date and time › device is taken into account in a scene calculation. I think it’s the ‹ timestamp › in seconds that could be used… - Have a clean display if I display a ‹ date and time › device on the dashboard, with the possibility to choose the display format ---
**Author:** ![cursor-bot](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cursor-bot/32/22252_2.png) [@cursor-bot](https://community.gladysassistant.com/u/cursor-bot)\ **Post date:** [August 18, 2026, 2:21am UTC](https://community.gladysassistant.com/t/recuperer-la-date-et-lheure-dans-une-scene/8821/3 "2026-08-18T02:21:57Z")
Hi everyone! This topic is now **under development**. A PR has been opened to add a scene action « Get date and time » (date, time, datetime and timestamp, with adjustable precision): > > > Implements feature request: https://community.gladysassistant.com/t/recuperer-la…-date-et-lheure-dans-une-scene/8821 > > \### Description > > This PR adds a new scene action, \*\*"Get the current date and time"\*\* (\`time.get-date\`), which makes the current local date/time available to the rest of the scene, without having to call an external web service. > > The action stores 4 variables in the scene scope, reusable in any following action (message text, MQTT payload, formula, condition…): > > | Variable | Example (precision "minute") | Usage | > |---|---|---| > | \`datetime\` | \`2026-08-18 15:32\` | Full date and time, truncated to the chosen precision | > | \`date\` | \`2026-08-18\` | Date only | > | \`time\` | \`15:32\` | Time only | > | \`timestamp\` | \`1787153520\` | Unix timestamp in seconds, usable in a calculation | > > Details: > > \- \*\*Precision\*\*: the user picks the granularity in the scene editor (second, minute, hour, day — default: minute), so a message doesn't end up more precise than needed (the forum request explicitly asks for this: "si Gladys me donne une info à la milliseconde, mon message va être inutilement précis"). The date/time is truncated (\`startOf\`) to that precision, and \`timestamp\` follows the same truncation. An unknown precision aborts the scene instead of storing an unusable date. > \- \*\*Timezone\*\*: the date is computed with \`dayjs.tz(..., self.timezone)\`, i.e. the timezone configured in Gladys, exactly like the existing \`condition.check-time\` and \`calendar.get-events\` actions. It is the local time of the user, not the time of the server. > \- \*\*Calculation\*\*: \`timestamp\` being a number in seconds, it covers the use case described in the topic — storing "now" in a device/variable in scene A, then in scene B computing \`({{0.0.timestamp}} - {{1.0.last\_value}}) / 60\` to say "the heat pump last started 26 minutes ago". > \- The action is also declared in the MCP scene schema (\`server/services/mcp/lib/sceneSchemas.js\`), so scenes created through the MCP server can use it too. > > \*\*Scope\*\*: the forum topic also floats two broader ideas — a virtual "date and time" \*\*device type\*\* and its rendering on the dashboard. Those are much bigger changes (data model + dashboard boxes), so this PR deliberately implements only the core, coherent piece that was asked for: a scene action exposing the current date/time as scene variables. > > This PR was created by an automated Claude Code run. > > \*\*Files changed\*\* > > \- \`server/utils/constants.js\`: new \`ACTIONS.TIME.GET\_DATE\` > \- \`server/lib/scene/scene.actions.js\`: the action implementation > \- \`server/services/mcp/lib/sceneSchemas.js\`: MCP schema for the new action > \- \`front/src/routes/scene/edit-scene/actions/GetDate.jsx\`: new action card (precision selector + variables declaration) > \- \`front/src/routes/scene/edit-scene/ActionCard.jsx\`, \`actions/ChooseActionTypeCard.jsx\`: registration of the action > \- \`front/src/config/i18n/{en,fr,de}.json\`: translations > \- \`server/test/lib/scene/actions/scene.action.getDate.test.js\`, \`server/test/services/mcp/lib/sceneSchemas.test.js\`: tests > > \## Forum > > Forum: https://community.gladysassistant.com/t/recuperer-la-date-et-lheure-dans-une-scene/8821 > > \### Checklist > > \- \[x\] Tests pass: \`cd server && npm run coverage\` (Codecov requires 100% coverage on changed lines) and Cypress (\`npm run cypress:run\`) if the UI changed > \- \[x\] Linter and prettier pass on both front and server (\`npm run eslint\`, \`npm run prettier\`) > \- \[x\] No undocumented breaking change > > Notes on the checklist: the server test suite was run locally (\`npm test\`, all scene and MCP tests green — the only failures in this sandbox are pre-existing environment ones: missing \`sqlite3\` CLI binary, no Docker socket, no network access to Gladys Plus). The front was validated with \`prettier-check\`, \`eslint\`, \`compare-translations\` and \`npm run build\`. Cypress was \*\*not\*\* run (the Cypress binary is not installed in this environment), but no existing UI route or component behavior was modified — only a new action card was added. > > \--- > 🤖 Generated with \[Claude Code\](https://claude.com/claude-code) > > \--- > \_Generated by \[Claude Code\](https://claude.ai/code/session\_01YXRz5JiaM9N42djviseBRu)\_ Feel free to follow the PR, test (optional, especially for small requests) and give your feedback here if needed. ---
**Author:** ![prohand](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/prohand/32/15713_2.png) [@prohand](https://community.gladysassistant.com/u/prohand)\ **Post date:** [August 20, 2026, 2:01pm UTC](https://community.gladysassistant.com/t/recuperer-la-date-et-lheure-dans-une-scene/8821/4 "2026-08-20T14:01:26Z")
I tested on my side, everything is ok 😉 ---
**Author:** ![mutmut](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/mutmut/32/14064_2.png) [@mutmut](https://community.gladysassistant.com/u/mutmut)\ **Post date:** [August 20, 2026, 2:21pm UTC](https://community.gladysassistant.com/t/recuperer-la-date-et-lheure-dans-une-scene/8821/5 "2026-08-20T14:21:42Z")
Cool if we no longer have to make an HTTP GET request to retrieve the date and time 😉 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/2/c/2cf345ccb23d097317f9d4ddc3f115c53fcb071b.png) But does this take into account the host Gladys’s time? Because I think I have a difference when I look at the logs and the corresponding times, 1 or 2 hours ☹ ---
**Author:** ![prohand](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/prohand/32/15713_2.png) [@prohand](https://community.gladysassistant.com/u/prohand)\ **Post date:** [August 20, 2026, 2:47pm UTC](https://community.gladysassistant.com/t/recuperer-la-date-et-lheure-dans-une-scene/8821/6 "2026-08-20T14:47:17Z")
It seems to take the host Gladys’s time ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/7/9/797c8c4fdb86cda6c1dcd845e5ee65c0cd1d1b98.png) The times in the logs of external integrations are in UTC I checked that the Gladys Docker logs are indeed in the correct timezone I will create a feature request for the timezone of external integrations ---
**Author:** ![cursor-bot](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cursor-bot/32/22252_2.png) [@cursor-bot](https://community.gladysassistant.com/u/cursor-bot)\ **Post date:** [August 28, 2026, 12:29pm UTC](https://community.gladysassistant.com/t/recuperer-la-date-et-lheure-dans-une-scene/8821/7 "2026-08-28T12:29:42Z")