Or require the value to specify a unit.

▲ mort96 14 hours ago | parent [-]

At that point, you're making all your configuration fields strings and adding another parsing step after the json/toml/yaml parser is done with it. That's not ideal either; either you write a bunch of parsing code (not terribly difficult but not something I wanna do when I can just not), or you use some time library to parse a duration string, in which case the programming language and time library you happen to use suddenly becomes part of your config file specification and you have to exactly re-implement your old time handling library's duration parser if you ever want to switch to a new one or re-implement the tool in another language.

I don't think there are great solutions here. Arguably, units should be supported by the config file format, but existing config file formats don't do that.

▲ notpushkin 14 hours ago | parent | next [-]

TOML has a datetime type (both with or without tz), as well as plain date and plain time:

  start_at = 2026-05-27T07:32:00Z  # RFC 3339
  start_at = 2026-05-27 07:32:00Z  # readable

We should extend it with durations:

  timeout = PT15S  # RFC 3339

And like for datetimes, we should have a readable variant:

  timeout = 15s   # can omit "P" and "T" if not ambiguous, can use lowercase specifiers

Edit: discussed in detail here: https://github.com/toml-lang/toml/issues/514

	▲	iririririr 6 hours ago \| parent [-]
		great, now attackers can also target all the libraries to enable all that complexity in npm too.

▲ dxdm 11 hours ago | parent | prev | next [-]

> adding another parsing step after the json/toml/yaml parser is done with it. That's not ideal either

I'd argue that it is ideal, in the sense that it's the sweet spot for a general config file format to limit itself to simple, widely reusable building blocks. Supporting more advanced types can get in the way of this.

Programs need their own validation and/or parsing anyway, since correctness depends on program-specific semantics and usually only a subset of the values of a more simply expressed type is valid. That same logic applies across inputs: config may come from files, CLI args, legacy formats, or databases, often in different shapes. A single normalization and validation path simplifies this.

General formats must also work across many languages with different type systems. More complex types introduce more possible representations and therefore trade-offs. Even if a file parser implements them correctly (and consistently with other such parsers), it must choose an internal form that may not match what a program needs, forcing extra, less standard transformation and adding complexity on both sides for little gain.

Because acceptable values are defined by the program, not the file, a general format cannot fully specify them and shouldn’t try. Its role is to be a medium and provide simple, human-usable (for textual formats), widely supported types, avoid forcing unnecessary choices, and get out of the way.

All in all, I think it can be more appropriate for a program to pick a parsing library for a more complex type, than to add one consistently to all parsers of a given file format.

▲ layer8 10 hours ago | parent | prev | next [-]

Another parsing step is the common case. Few parameters represent untyped strings where all characters and values are valid. For numbers as well, you often have a limited admissible range that you have to validate for. In the present case, you wouldn’t allow negative numbers, and maybe wouldn’t allow fractional numbers. Checking for a valid number isn’t inherently different from checking for a regex match. A number plus unit suffix is a straightforward regex.

▲ 13 hours ago | parent | prev [-]

[deleted]