Earlier quoted context omitted.
What timezone do you assume the source datetime is in?
UTC, of course: the only sensible timezone to store date and time in.
Until everyone starts using stardate or something similar :)
Uniform eXchange Format (UXF) – plain text human readable typed storage format
51–60 of 62 posts
Re: Uniform eXchange Format (UXF) – plain text human readable typed storage format
#52Re: Uniform eXchange Format (UXF) – plain text human readable typed storage format
#53Earlier quoted context omitted.
Since there are three incorrect responses to this comment already: 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-c…
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 an…
Why UTC instead of TAI?
Re: Uniform eXchange Format (UXF) – plain text human readable typed storage format
#54Re: Uniform eXchange Format (UXF) – plain text human readable typed storage format
#55Earlier quoted context omitted.
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 an…
Why UTC instead of TAI?
Because that’s not what TAI is designed for. UTC is for civil time keeping, and that’s what everything except highly-specialised stuff is tied to. The ISO 8601/RFC 3339 serialisation is UTC-based, so you’ll have to go heavily non-standard to use TAI, and you’ll find a complete lack of support in general date time libraries, so 37 second errors are sure to crop up all over the place if others ever touch things.
Re: Uniform eXchange Format (UXF) – plain text human readable typed storage format
#56This seems unnecessarily terse. If you want types, why not make it look like one of the existing popular languages with types? (Rust/TypeScript/protobuf) 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 ) ] Why not: type Data…
> Evidence shows that people like that kind of format,
I agree, but I don't know that why people like that kind of format is settled. I suspect it's because the majority of today's software has to touch the web, and the only programming language built into web browsers happen to consume and produce that kind of format natively.
In other words, I think it's popular, but I think it's popular because it's the path of least resistance for interfacing with the web, which isn't necessarily a priority all the time.
Re: Uniform eXchange Format (UXF) – plain text human readable typed storage format
#57Earlier quoted context omitted.
Since there are three incorrect responses to this comment already: 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-c…
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 an…
It isn't nitpicking, it's really a different type: 15 oct 2022 at 19:01 CET with DST, i.e. an instant, vs. 15 oct 2022 at 19:01 in an unspecified time zone, i.e. a set of about 25 instants (one per possible timezone).
While a datetime without a timezone isn't terribly useful, distinguishing it from a datetime and timezone designation pair is the only correct type system.
Re: Uniform eXchange Format (UXF) – plain text human readable typed storage format
#58Re: Uniform eXchange Format (UXF) – plain text human readable typed storage format
#59That's human-readable is it? Personally I find the TOML example far easier to read, it doesn't seem to be spelt out what the 'advantage' is in translating to UXF; I think maybe that it supports custom types? A comparison to Recfiles (which do) would be nice then. https://en.wikipedia.org/wiki/Recfiles https://www.gnu.org/software/recutils/
TOML has a mess of separators (lines and commas) with confusingly optional delimiters instead of whitespace as separator and mandatory string delimiters: possibly nicer to write, but more complex, with unnecessary ambiguities, and less elegant.
Re: Uniform eXchange Format (UXF) – plain text human readable typed storage format
#60Earlier quoted context omitted.
True/false is more widely used than yes/no in this context. The fact that the author felt the need to explain that yes/no maps to true/false indicates that they also believe this to be the case. The only time I can remember seeing yes/no used in a format like this is YAML, and that caused problems[1]. [1]: https://hitchdev.com/strictyaml/why/implicit-typing-removed/
The Norway problem came to mind for me, too, but I don't think there's much opportunity for that to arise here given that strings are quoted. Meanwhile, there's plenty of other precedent for yes/no instead of true/false; shell scripts come to mind. I don't know if I prefer this over treating everything as a string and letting readers/writers decide on their own how to parse things, but it seems like a much more reaso…
Yes, I agree, the format described here is more reasonable than YAML and would not suffer from the Norway problem.
I'm interested in what you mean when you mention shell scripts; I find it more idiomatic to write:
if [ true ]; then echo test; fi
if [ yes ]; then echo test; fi
while true; do echo test; done
yes | while read _; do echo test; done
while yes | :; do echo test; done
yes no