21–30 of 62 posts
> Use no for false and yes for true. Wouldn’t it be better to use true for true and false for false?
Could you please elaborate? Why is true a better value than yes? Seems like an arbitrary choice to me. Does one choice have some advantages over the other?
Earlier quoted context omitted.
No time zones ever. If I see a date and its X, I know that I only need to add y to get my timezone to know when this happened. but if anybody puts a timezone there, now I can't do it mentally.
What timezone do you assume the source datetime is in?
> Use no for false and yes for true. Wouldn’t it be better to use true for true and false for false?
Could you please elaborate? Why is true a better value than yes? Seems like an arbitrary choice to me. Does one choice have some advantages over the other?
Maybe for communication between trusted parties? Then I would use a binary format.
Earlier quoted context omitted.
Could you please elaborate? Why is true a better value than yes? Seems like an arbitrary choice to me. Does one choice have some advantages over the other?
Well, "false" can't get confused with the ISO code for Norway.
Instead of:
uxf 1
=Database server:str ports:list connection_max:int enabled:bool
=DateTime when:datetime tz:str
=Owner name:str dob:DateTime
=Hosts name:str
[
(Owner (DateTime 1979-05-27T07:32:00 ))
(Database [8000 8001 8002] 5000 yes)
(Hosts
)
]
type Database {
server: str,
ports: list,
connection_max: int,
enabled: bool,
}
type DateTime {
when: datetime,
tz: str,
}
type Owner {
name: str,
dob: DateTime,
}
type Hosts {
name: str,
}
[
Owner('Tom Preston-Werner', DateTime('1979-05-27T07:32:00', '-08:00')),
Database('192.168.1.1', [8000, 8001, 8002], 5000, yes),
[
Hosts('alpha'),
Hosts('omega'),
],
]
What's the point of a plain-text format that is not human-friendly? Especially for type definitions, do you expect people to write this or do you want them to compile their schema from a different human-readable format into your human readable-format (and why)?
Earlier quoted context omitted.
No time zones ever. If I see a date and its X, I know that I only need to add y to get my timezone to know when this happened. but if anybody puts a timezone there, now I can't do it mentally.
What timezone do you assume the source datetime is in?
Anyone saying “UTC” is wrong. Unambiguously wrong if offsets are supported, and in foolish contexts like this where offsets are not supported, still wrong due to common sense and custom.
If there is no offset, there is no offset. It’s what is commonly called a naive or plain datetime. How it should be interpreted is explicitly undefined if offset-capable, and implicitly undefined by strong custom if not offset-capable; but it will generally mean in the local time zone, whatever that is—and it could be relative to a particular machine or a particular user. This is often suitable for social use, but completely unsuitable for machine history-recording use.
So: the question is rhetorical, unanswerable, thereby demonstrating why nmz’s position is unreasonable.
(Actually, only probably unreasonable because nmz’s wording wording with its “X” and “y” is not clear and may be using the term “timezone” subtly—the trouble is it’s used to mean three different things: firstly and most properly, a name for a set of rules about which time offsets to use when, e.g. “Australian Eastern Time” or “Australia/Melbourne” as it’s called in the IANA Time Zone Database, which roughly means AEST (+10:00) for half the year and AEDT (+11:00) for the other half, but conveys the rules as they have been through time; secondly, a somewhat less correct colloquial usage, a named time offset, e.g. “AEDT” or “Australian Eastern Daylight Saving Time” for +11:00; and thirdly, fairly clearly into the realm of misuse but still very common, a time offset like “+11:00”. If nmz was using the term “timezone” more precisely to mean one of the named concepts and expressly not an offset, then yeah, times written that way do require memorising a whole database, whereas offsets are straightforward to calculate, though it’s definitely harder having to do two calculations than the just one if it starts at UTC.)
https://github.com/tlocke/zish
Any comments / criticisms gratefully received.
This format does a lot of things correctly conceptually, in my opinion. 1. It supports data tables with named and typed columns. 2. It supports types in the header that can be referenced elsewhere. 3. It supports lists of stuff as well as types and nesting. 4. It uses a format header to easily declare what format to decode/encode. Unlike lists of JSON objects, the data can be represented more compactly. I've done som…
Any links to share? I think your feedback is very spot on so curious what you've built.