Uniform eXchange Format (UXF) – plain text human readable typed storage format

This is very very good. Only thing I can think that it's missing (and maybe you have support for this and I misread your readme) is ordered maps (there's a better name for this but I'm blanking).

For example, imagine I have a compact append only map format and I want to represent it like this (where last tuple wins when you have a duplicate key, but earlier history is preserved)

    {
     score: 0,
     score: 1
    }

If you want to make this a nitpicking discussion about phrasing a provocative statement, sure. If we’re talking about what matters, I stand by the notion that any point in time should be recorded in UTC, full stop. Storing a different time zone only makes sense if something happens at the same time in multiple time zones, but use cases are few. In the vast majority of scenarios,calculating the offset of the client and showing the adjusted date is the correct solution.

I really fail to see the point of this format.

If human readability was the point, then doing something different than expected is a really bad idea:

* "no" and "yes" as boolean values may save some bytes, but the tradeoff isn't worth it (and if filesize matters, use a binary format to begin with). * Using angle braces except of double quotes to fence strings makes the format look noisy and means you have to remember two kinds of escapes if you want to use in the value. * The format isn't object oriented in any way. You can simulate that by putting maps into maps, of course, but no one will have fun reading or writing that in a text editor.

Type information is for parsers, not humans. JSON this this right, Protobuf does this right. UXF is just a compromise combining (only) the disadvantages of the two.

UXF is self contained, that's great, but in 99.9% of the cases where you need a DX format, sender and receiver already know the schema, so that definition block just adds bloat.

You can happily mix lists, maps and tables of primitive or compound types. And since stuff is typed instead of named, order matters and you end up addressing everything through positional parameters. That's going to be fun when using a text editor to write down something like a list of GPS coordinates (you are likely to confuse latitude and longitude).

You're in luck though, because nobody is ever going to use this format.

The context was specifically the handling of times that don’t include an offset (or perhaps time zone, it was unclear). The correct answer there is not UTC (which is flatly incorrect, depending on a locally-enforced convention that incidentally deviates from the most common meaning of such time stamps), but rather “don’t enter that situation in the first place, because any other answer is wrong”.

—⁂—

For the rest of your statement: for times not tied to a particular location or time offset, you should always use UTC in the form of the offset Z, in ISO 8601/RFC 3339 terms, since specifying any other offset indicates that it means something. (Note that RFC 3339 tried to have -00:00 be the neutral offset and Z and +00:00 meaningful, but that is acknowledged to have failed, and so https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e... is updating it to match actual usage.) But for things that involve humans and are anchored to a particular time zone, using UTC and not storing a time zone is wrong: you should store the relevant time zone and (fallback) offset so that if the time zone definition changes (as they do, sometimes with less than a few days’ notice), future times can be corrected, which they can’t be if you anchored them to UTC. So: things like system logs, use UTC; online conferences, use UTC; location-bound conferences, use that location’s time zone; general user calendars, use the user’s time zone; calendars for companies that straddle time zones (or people that work across time zones): deliberately choose a time zone or offset to anchor things to (sometimes at the level of individual events), especially for the sake of recurring event periods if you use a time zone with DST.