←back to thread

Show HN: Duper – The Format That's Super

(duper.dev.br)
31 points epiceric | 3 comments | 01 Nov 25 23:41 UTC | HN request time: 0.001s | source

An MIT-licensed human-friendly extension of JSON with quality-of-life improvements (comments, trailing commas, unquoted keys), extra types (tuples, bytes, raw strings), and semantic identifiers (think type annotations).

Built in Rust, with bindings for Python and WebAssembly, as well as syntax highlighting in VSCode. I made it for those like me who hand-edit JSONs and want a breath of fresh air.

It's at a good enough point that I felt like sharing it, but there's still plenty I wanna work on! Namely, I want to add (real) Node support, make a proper LSP with auto-formatting, and get it out there before I start thinking about stabilization.

Show context
anonzzzies ◴[02 Nov 25 06:40 UTC] No.45788275[source]▶
Why no date and time?
replies(1): >>45788776 #
epiceric ◴[02 Nov 25 08:37 UTC] No.45788776[source]▶
My reasoning is that they are normally transmitted as strings in JSON, and you could use an identifier like DateTime("2025-11-02T02:33:00Z") if you need to be explicit.

Making them part of the language would increase the complexity of parsers - how would you validate that a date is actually valid? It's doable (YAML and TOML do it, after all) but requires extra steps.

replies(1): >>45790314 #
1. epiceric ◴[02 Nov 25 13:45 UTC] No.45790314[source]▶
Although given the feedback I've received, date/time might get included into the format.
replies(2): >>45791343 #>>45807165 #
2. jitl ◴[02 Nov 25 16:14 UTC] No.45791343[source]▶
note that a DateTime w/ a UTC offset is significantly different from a DateTime w/ a TimeZone (+ optional Calendar), aka ZonedDateTime. ZonedDateTime(July 26, 2035 10:15:32pm in Instanbul) may not necessarily always be at today's value of Instant(July 26, 2035 10:15:32pm in Instanbul). If you are going to support date/time, you should not use the word "DateTime", "Date", "Time" in a way that is ambiguous (is it a ZonedDateTime, or an Instant?), or forget to include support for ZonedDateTime.

MDN page on JavaScript's Temporal library gives a good overview of the difference between the two; today's practice of encoding Instants as ISO 8601 strings in UTC (Z suffix) or at a UTC offset is okay for ephemeral data-in-motion that will be used right now, but is not a good practice for persisted data since time zones, DST rules, etc change all the time. Temporal is the JS-specific API, but these concepts apply to all handling of date/time/etc data in computer systems.

That said, v8 plans to use [temporal_rs][] as their Temporal backend.

Temporal: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

temporal_rs: https://crates.io/crates/temporal_rs

You can encode extended ZonedDateTime information to string following this RFC [Date and Time on the Internet: Timestamps with Additional Information](https://www.rfc-editor.org/rfc/rfc9557.txt)

3. djfobbz ◴[04 Nov 25 03:27 UTC] No.45807165[source]▶
DateTime handling, especially with timezone offsets, is crucial. If your format gets that right, it'll stand out...most formats still mess up time zones or rely on loose string parsing. It's key for stuff like logs, scheduling, or syncing data across systems. DuperGZ right after that! ;)