Switched Datetime format for <environment_details> to something clearer (ISO)

[Helmi]

Context

The datetime format for <environment_details> was weird and had the potential to confuse LLMs.

For example it used an international date format that was not defined and fell back to local. In my case (German) todays date output was 6.4.2025 which got confused by LLM for June 4th multiple times (instead of April 6th).

The forced time format of 12h which is completely not used in germany probably added to that confusion.

Implementation

I changed the date format to a proper ISO format including the timezone offset to keep the local relation.

Get in Touch

@Helmi on discord.

---

Important

Changed datetime format in Cline.ts to ISO with timezone offset for clarity in getEnvironmentDetails().

• Datetime Format Change:
  • In Cline.ts, changed datetime format to ISO with timezone offset in getEnvironmentDetails().
  • Replaced custom formatting logic with toISOString() and manual timezone offset calculation.
  • Removed trailing 'Z' from ISO string and appended custom offset.

^{This description was created by for d0c725a. It will automatically update as commits are pushed.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: d0c725a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ellipsis-dev]

The new implementation for formatting the current time is problematic: it uses now.toISOString() (which always returns a UTC timestamp) and then simply removes the trailing 'Z' and appends the local timezone offset. This does not convert the time portion to local time. For example, in a timezone of UTC+01:00, if the real local time is 12:00, toISOString() might yield 11:00Z, and the result becomes "11:00+01:00" instead of the correct local time 12:00. Consider converting the date to local values (using native Date methods or a date library) before formatting, so the time and offset are consistent. This issue should be fixed to reliably display the correct local time.

[Helmi]

Actually flawed. closing this for now - sending a new one.