Eden treaty converts strings to dates

[KuceraMartin]

What version of Elysia is running?

1.4.25

What platform is your computer?

Darwin 25.2.0 arm64 arm

What steps can reproduce the bug?

import { Elysia } from 'elysia'
import { treaty } from '@elysiajs/eden'
import { z } from 'zod'

const app = new Elysia()
  .get('/test', () => "04/02/2026", {
    response: z.string()
  })

const api = treaty(app)
const res = await api.test.get()
if (res.error === null) {
  console.log(typeof res.data)
  console.log(res.data)
} else {
  console.error(res.error)
}

What is the expected behavior?

prints to console:

string
04/02/2026

What do you see instead?

prints to console:

object
2026-04-02T00:00:00.000Z

Additional information

My understanding is that Elysia tries to convert all strings that look like dates to Date objects, so what I'm describing is in some way a feature. I hope the example above illustrates why I see it as a bug. An endpoint might be returning a generic string that comes from a user's input and we don't control its format. If it happens to look like a date and we try to treat it as a string on the frontend, we have a problem.

Have you try removing the node_modules and bun.lockb and try again yet?

No response

[KuceraMartin]

I just found out that this behaviour can be turned off by initializing the treaty as

const api = treaty(app, { parseDate: false })

But of course, this causes issues elsewhere: actual Date objects now become strings.

Basically both options suck. I wonder if there is a better way to solve this. Would it be feasible to use the response schemas to only convert dates for fields that actually are of type Date? I know it's not required to provide a schema but at least it would solve the problem partially.

Another idea that would actually be good enough for my use-case: when eden treaty is initialized with parseDate: false, convert all Date types in all responses to string. I don't mind if I have to wrap them in new Date(...) manually on the frontend. I do mind if the types are wrong though, because then I get code that typechecks and crashes at run time.

[ConnectivityChris]

I just found out that this behaviour can be turned off by initializing the treaty as

const api = treaty(app, { parseDate: false })

But of course, this causes issues elsewhere: actual Date objects now become strings.

This was my exact problem with this PR #245 the other week when they option got merged

It's very all or nothing approach to the problem and just bypasses the typing/parsing system alltogether

[ngryman]

The current behaviour is confusing.

1. Parsing dates should be an opt-in, not a default.
2. It should be dependent on the response's schema. If one asks for a z.date, then it should attempt to parse it, otherwise it should leave it as is.