fix(codegen): change DateTime type to string in TypeScript generation

[apoorv7g]

fix(typescript): map Concerto DateTime to string in generated types

Closes #257

When generating TypeScript interfaces from Concerto models, the DateTime primitive was mapped to the TypeScript Date type. In JSON and at runtime, DateTime values are represented as ISO-8601 strings (for example, "2026-06-27T13:14:00.000Z"). This mismatch caused strict TypeScript compilation errors when logic code assigned values such as new Date().toISOString() to DateTime fields a common pattern in Template Playground logic files.

This PR updates toTsType in TypescriptVisitor to map DateTime to string, aligning generated types with how Concerto data is actually serialized and consumed over JSON.

Changes

• Map the Concerto DateTime primitive to string instead of Date in TypescriptVisitor.toTsType (lib/codegen/fromcto/typescript/typescriptvisitor.js)
• Update generated TypeScript output for DateTime fields, scalar aliases (e.g. Time), and map key/value types (e.g. Map<string, string> instead of Map<string, Date>)
• Update unit tests in test/codegen/fromcto/typescript/typescriptvisitor.js for scalar declarations, map declarations, and toTsType
• Update codegen snapshot expectations in test/codegen/__snapshots__/codegen.js.snap for affected interfaces (ITransaction, IEvent, IPerson, etc.)

Flags

• Breaking change for TypeScript consumers: Any project that relied on generated interfaces typing DateTime fields as Date will need to regenerate types and update code that assigns Date objects directly. JSON-backed workflows (Template Playground, Cicero logic, etc.) are the intended beneficiaries and should require no runtime changes.
• string vs Date | string: string was chosen deliberately because Concerto JSON serialization always represents DateTime as an ISO-8601 string. A union type would imply both forms are equally common at runtime, which is not the case for JSON payloads.
• Scope limited to TypeScript: Other language targets (Java, C#, Rust, etc.) are unchanged and continue to use their own native date/time types.
• No documentation update required: This is an internal codegen behavior fix; generated output changes are reflected in tests and snapshots.

Before (generated TypeScript):

export interface ITransaction extends IConcept {
   $timestamp: Date;
}

export interface IPerson extends IParticipant {
   dob: Date;
}

After (generated TypeScript):

export interface ITransaction extends IConcept {
   $timestamp: string;
}

export interface IPerson extends IParticipant {
   dob: string;
}

Related Issues

• Issue fix(codegen): TypescriptVisitor maps DateTime to Date instead of string | Date causing TS compilation errors #257
• accordproject/template-playground#928 (downstream context: Template Playground logic files failing strict TypeScript checks when returning ISO timestamp strings)

Author Checklist

• Ensure you provide a DCO sign-off for your commits using the --signoff option of git commit.
• Vital features and changes captured in unit and/or integration tests
• Commits messages follow AP format
• Extend the documentation, if necessary (not required for this change)
• Merging to main from fork:branchname

[23harshitkumar]

Thanks a lot for this PR @apoorv7g!

[apoorv7g]

@mttrbrts can this be merged , this resolves #257 @23harshitkumar would appreciate it.

[mttrbrts]

Great to see the collaboration both! @apoorv7g @23harshitkumar

Is there a solution that doesn't require a breaking change? E.g. parsing the ISO string to create TypeScript Date objects?

[apoorv7g]

@mttrbrts the parsing can only happen on the client side i.e. outside codegen. If we want the parsing within our repository we cannot do it with a small change as these are compile-time attributes , we might have to create new classes, functions etc. @23harshitkumar Please confirm.

[23harshitkumar]

@mttrbrts Yes, I can confirm what @apoorv7g is saying. Since codegen only generates TS interfaces (which vanish entirely at runtime), there's no place to insert parsing logic. To do that, we would need to do some pretty good changes to the codegen.

From the Playground side, all contract data flows through JSON, where dates are always ISO strings. Mapping DateTime to string correctly reflects the actual runtime data. I also considered a string | Date union as a non-breaking compromis but it still breaks any code that calls Date-specific methods like .getFullYear(), so it doesn't fully solve the problem either.