kogasa

I'm a .NET dev, I don't have a concept of "just use a library." Everything is a library. I don't mean "using int for datetimes is ok as long as you label it utc," I just mean "don't deal with time zones."

IMO every datetime should be in utc, and variables for datetimes should either be suffixed "Utc" or have a type indicating their time zone (DateTimeOffset or UtcDateTime etc). Conversion to local time happens at the last possible second (e.g. in the view model or an outbound http request parameter). Of course that doesn't solve the problem of interoperating with other ~~morons~~ programmers who don't follow these rules, but it keeps things a lot neater locally.

Scheduling based on regional time conventions (holidays, weekends, etc) is just not great though.

The obvious solution is to inject an IWeekendDaysOfWeekProvider service in the inversion of control container. In your, uh, javascript web app.

I've disagreed with JavaScript before, what makes you think I won't do it again?

Anyway, anything using JSON as a config language will also certainly use a JSON interpreter that can ignore comments. Sure that's "implementation specific," but so is a config file. You wouldn't use "MyApplication.config.json" outside the context of MyApplication loading its own configuration, so there's no need for it to be strictly compliant JSON as long as it plays nicely with most text editors.

Toml

If a comment isn't part of the semantic content of a JSON object it has no business being there. JSON models data, it's not markup language for writing config files.

You can use comments in JSON schema (in a standardized way) when they are semantically relevant: https://json-schema.org/understanding-json-schema/reference/comments

For the data interchange format, comments aren't part of the JSON grammar but the option to parse non-JSON values is left open to the implementation. Many implementations do detect (and ignore) comments indicated by e.g. # or //.

Serializing isn't necessarily about performance, or we'd just use protobuf or similar. I agree Json is a great all rounder. Combine with JSON object schema to define sophisticated DSLs that are still readable, plain JSON. TOML is nice as a configuration language, but its main appeal (readability) suffers when applied to complex modeling tasks. XML is quite verbose and maybe takes the "custom DSL" idea a little too far. YAML is a mistake.

RCS is not SMS and has nothing to do with the SMS standard.

That has nothing to do with file transfer ("updating"), just long term storage. It's also a solved problem. You can solve it at the software level with modern self-healing filesystems.

You can get a housing that lets you pop it in and out

And Star Trek and Star Wars and probably Galaxy Quest

Eh? You can verify bit for bit that a digital transfer off an SSD was successful.