5 ms·

About the use of different units: next time you choose a property name in a config file, include the unit in the name. So not “timeout” but “timeoutMinutes”.

weird-eye-issue 6mo ago
timeoutMs is shorter ;) You guys can't appreciate a bad joke
- sayamqazi 6mo ago
  not timeout at all is even shorter.
- cozzyd 6mo ago
  Megaseconds are about the right timescale anyway
  - torben-friis 6mo ago
    What megaseconds? They clearly meant the Microsoft-defined timeout.
    - cozzyd 6mo ago
      Well megaseconds has the nice property that it's about about equal to a Scaramucci so it can be used across domains.
- withinboredom 6mo ago
  timoutμs is even better. People will learn how to type great symbols.
  - johnisgood 6mo ago
    Yes timout indeed!
  - funcDropShadow 6mo ago
    They wouldn't have to, if the file format accepted floats in proper exponential format.
layer8 6mo ago
Or require the value to specify a unit.
- mort96 6mo ago
  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 6mo ago
    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 https://github.com/toml-lang/toml/issues/514
    - iririririr 6mo ago
      great, now attackers can also target all the libraries to enable all that complexity in npm too.
  - deleted 6mo ago
    [deleted]
  - dxdm 6mo ago
    > 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.
deleted 6mo ago
[deleted]
s1mn 6mo ago
Yes!! This goes for any time you declare a time interval variable. The number of times I've seen code changes with a comment like "Turns out the delay arg to function foo is in milliseconds, not seconds".

weird-eye-issue 6mo ago

timeoutMs is shorter ;) You guys can't appreciate a bad joke

sayamqazi 6mo ago
not timeout at all is even shorter.
cozzyd 6mo ago
Megaseconds are about the right timescale anyway
- torben-friis 6mo ago
  What megaseconds? They clearly meant the Microsoft-defined timeout.
  - cozzyd 6mo ago
    Well megaseconds has the nice property that it's about about equal to a Scaramucci so it can be used across domains.
withinboredom 6mo ago
timoutμs is even better. People will learn how to type great symbols.
- johnisgood 6mo ago
  Yes timout indeed!
- funcDropShadow 6mo ago
  They wouldn't have to, if the file format accepted floats in proper exponential format.

layer8 6mo ago

Or require the value to specify a unit.

mort96 6mo ago
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 6mo ago
  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 https://github.com/toml-lang/toml/issues/514
  - iririririr 6mo ago
    great, now attackers can also target all the libraries to enable all that complexity in npm too.
- deleted 6mo ago
  [deleted]
- dxdm 6mo ago
  > 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.

deleted 6mo ago

[deleted]

s1mn 6mo ago

Yes!! This goes for any time you declare a time interval variable. The number of times I've seen code changes with a comment like "Turns out the delay arg to function foo is in milliseconds, not seconds".