Chronera (@intech-software/chronera)

One date, two ways to read it

A project completed in September 2026 should appear as 09/2026 in English and 09/2569 in Thai. It is still the same project month. Changing the language should change the display, not the stored value.

That distinction guides this integration. Content keeps Gregorian ISO dates. A shared adapter parses and formats them with explicit calendar and timezone options. Invalid dates are rejected before publication, and regression tests cover leap days, year boundaries and Thai midnight.

Try Chronera with runnable examples. Change a date, compare timezones or add days across a year boundary, then copy the code that produced the result.

Keep a date separate from a moment in time

A project month does not need a timezone. A timestamp does. This example starts with an explicit UTC instant and displays it in Bangkok and UTC:

import { parseInstant, formatWithPattern } from '@intech-software/chronera';

const instant = parseInstant('2026-10-18T17:30:00Z');
console.log(
  formatWithPattern(instant, 'dd/MM/yyyy HH:mm', {
    locale: 'th-TH',
    calendar: 'buddhist',
    numberingSystem: 'latn',
    timeZone: 'Asia/Bangkok',
  }),
);
console.log(
  formatWithPattern(instant, 'dd/MM/yyyy HH:mm', {
    locale: 'en-GB',
    calendar: 'gregory',
    numberingSystem: 'latn',
    timeZone: 'UTC',
  }),
);

The results are 19/10/2569 00:30 and 18/10/2026 17:30. The date changes because Bangkok is ahead of UTC; both values describe the same instant. This example is checked against release 0.2.8, not an unversioned development branch.

What “no runtime dependencies” covers

The published 0.2.8 package manifest declares an empty dependencies object. That is the scope of the runtime dependency claim. It does not mean that this website, the build tools or every optional integration has no dependencies.

The package declares Zod, Valibot and SuperJSON as optional peer dependencies for their respective integrations. Those integrations need the corresponding host packages. The website’s date adapter does not import them. The package requires Node.js 22.14 or newer; the website uses Node.js 24 and has its own higher minimum runtime requirement.

Fewer runtime packages do not guarantee security. The library’s own code, optional integrations, build chain and deployment environment still need review and updates. Locale and timezone formatting also relies on the runtime’s Intl support and data, so supported environments need their own tests.

Performance claims need a reproducible report

We do not publish a throughput ranking, bundle-size figure or fixed test count here. The earlier figures did not have a linked run report identifying the machine, runtime and exact revision, so they cannot support a repeatable comparison.

The repository includes a microbenchmark suite at the 0.2.8 source revision. Its existence is not a measured result. Before publishing numbers, a report needs:

• The package version, source commit and exact comparison-library versions.
• CPU, memory, operating system and exact Node.js/V8 versions.
• The command, input data, timezone, warm-up and sampling settings, and cache conditions.
• Raw output from repeated runs, units and variability, with equivalent work on each side.
• For bundle size, the entry point, bundler settings and compression method.

A microbenchmark measures a narrow operation under those conditions. It does not establish the loading speed of this website or performance in a customer’s application.

Sources and next steps

This case study describes the 0.2.8 release used by the website. It is not a claim about the latest release or every feature in the library.

• Published npm release and dependency metadata
• Source manifest at commit 5361d661
• Documentation at the same source revision
• Open the playground and quickstart

Start with the date rules your application actually needs. Try them in the playground, then test those same rules in your target runtime before adopting the package.