There are a couple I have in mind. Like many techies, I am a huge fan of RSS for content distribution and XMPP for federated communication.
The really niche one I like is S-expressions as a data format and configuration in place of json, yaml, toml, etc.
I am a big fan of Plaintext formats, although I wish markdown had a few more features like tables.
ISO 8601 date format. Not because it’s a standard, but because it’s simple, sensible, clearly defined, and very effective.
Date fields in any order other than most-significant-digits-first is not only counterintuitive, but needlessly complicated to work with. Omitting critical information like the century is ambiguous and confusing.
We don’t live in isolated villages any more. Mixing and matching those problems by accepting all the world’s various regional and personal date styles, especially with no reliable indication of which ones apply in any given case, leads to the hodgepodge of error-prone date madness that we have today.
The 2024-09-02 format should be taught in schools and required in official documents. Let the antiquated date styles fall into disuse outside of art and personal correspondence, like cursive writing.
RFC3339 is a simplified profile of 8601 that only covers YYYY-MM-DD style formatting, if you only ever use that format and avoid the things like “2024-W36” they’re mostly interchangeable.
Also, you can sort by ascending file names
I arrived to manage releases in a company, the previous manager named releases as “release04092016”, as USA standard. My first recommendation was to name releases as “releaseyyyymmdd” so “release20160409”. I was asked by another manager why to change that, so I showed her a sorted list of releases “git branches” and asked her, can you tell me there when was the last release? (a very common question) Of course, to find the last release you need to check the whole list because the mmddyyyy order is useless. The answer with yyyymmdd was immediate, just look at the last row.
I had the fortune of being hired to build up from zero my department, and one of the first “rules” I made was all dates are ISO-8601 and now every process runs with 8601, if you use anything different your code is going to fail eventually when it finds another column date in 8601.
I love this standard. If you dig deeper into it, the standard also covers a way to express intervals and periods. E.g. “P1Y2M10DT2H30M” represents one year, 2 months, 10 days, 2 hours and 30 mins.
I recall once using the standard when writing a cron-style scheduler.
I also like the POSIX “seconds since 1970” standard, but I feel that should only be used in RAM when performing operations (time differences in timers etc.). It irks me when it’s used for serialising to text/JSON/XML/CSV.
Also: Does Excel recognise a full ISO8601 timestamp yet?
I also like the POSIX “seconds since 1970” standard, but I feel that should only be used in RAM when performing operations (time differences in timers etc.). It irks me when it’s used for serialising to text/JSON/XML/CSV.
I’ve seen bugs where programmers tried to represent date in epoch time in seconds or milliseconds in json. So something like “pay date” would be presented by a timestamp, and would get off-by-one errors because whatever time library the programmer was using would do time zone conversions on a timestamp then truncate the date portion.
If the programmer used ISO 8601 style formatting, I don’t think they would have included the timepart and the bug could have been avoided.
Use dates when you need dates and timestamps when you need timestamps!
Thats an issue with the time library, not with timestamps. Actually timestamps are always in UTC, you need to do the conversion to your local time when displaying the value. There should be no possible off-by-one errors, unless you are doing something really wrong.
And it can be sorted alphabetically in all software. That’s a pretty big advantage when handling files on a computer
The year is the information that most of the time is the least significant in a date, in day to day use.
DDMMYY is perfect for daily usage.
Your day to day use isn’t everyone else’s. We use times for a lot more than “I wonder what day it is today.” When it comes to recording events, or planning future events, pretty much everyone needs to include the year. Getting things wrong by a single digit is presented exactly in order of significance in YYYY-MM-DD.
And no matter what, the first digit of a two-digit day or two-digit month is still more significant in a mathematical sense, even if you think that you’re more likely to need the day or the month. The 15th of May is only one digit off of the 5th of May, but that first digit in a DD/MM format is more significant in a mathematical sense and less likely to change on a day to day basis.
For any scheduled date it is irrelevant if you miss it for a day, a month or a year. So from that perspective every part of it is exactly the same, if the date is wrong then it is wrong. You say that it is sorted in the order of most significants, so for a date it is more significant if it happend 1024, 2024 or 9024? That may be relevant for historical or scientific purposes but not much people need that kind of precision. Most people use calendars for stuff days or month ahead or below, not years or decades.
If I get my tax bill, I don’t care for the year in the date because I know that the government wants the money this year not next or on ten. If I have a job interview, I don’t care for the year, the day and months is what is relevant. It has a reason why the year is often removed completely when dates are noted or made. Because it Is obvious.
Yes I can see why YYYY-MM-DD is nice for stuff like archiving purposes, it makes sorting and grouping very easy but there they already use the best system for the job.
For digital documents I would say that date and time information should be stored in a defined computer readable standard so that the document viewer can render or use it in any way needed. That could be swatch internet time as far as I care because hopefully I would never look at the raw data at all.
You say that it is sorted in the order of most significants, so for a date it is more significant if it happend 1024, 2024 or 9024?
Most significant to least significant digit has a strict mathematical definition, that you don’t seem to be following, and applies to all numbers, not just numerical representations of dates.
And most importantly, the YYYY-MM-DD format is extensible into hh:mm:as too, within the same schema, out to the level of precision appropriate for the context. I can identify a specific year when the month doesn’t matter, a specific month when the day doesn’t matter, a specific day when the hour doesn’t matter, and on down to minutes, seconds, and decimal portions of seconds to whatever precision I’d like.
Ok, then I am sure we will all be using that very soon, because abstract mathematic definitions always map perfectly onto real world usage and needs.
It is not that I don’t follow the mathematic definition of significance, it is just invalid for the view and scope of the argument that I make.
YYYY-MM-DD is great for official documents but not for common use. People will always trade precision for ease of use, and that will never change. And in most cases the year is not relevant at all so people will omit it. Other big issue: People tend to write like they talk and (as far as I know) nobody says the year first. That’s exactly why we have DD-MM and MM-DD
YYYY-MM-DD will only work in enforced environments like official documents or workspaces, because everywhere else people will use shortcuts. And even the best mathematic definition of the world will not change that.
DDMMYY is perfect for daily usage.
Except that DDMMYY has the huge ambiguity issue of people potentially interpreting it as MMDDYY. And it’s not straight sortable.
My team switched to using YYYY-MM-DD in all our inner communication and documents. The “daily date use” is not the issue you think it is.
Except that DDMMYY has the huge ambiguity issue of people potentially interpreting it as MMDDYY.
Yes and YYYY-MM-DD can potentially be interpreted as YYYY-DD-MM. So that is an zero argument.
I never said that the date format should never used, just that significants is a arbitrary value, what significant means depends on the context. If YYYY-MM-DD would be so great in everyday use then more or even most people would use it, because people, in general, tend to do things that make their life easier.
There is no superior date format, there are just date format that are better for specific use cases.
My team switched to using YYYY-MM-DD in all our inner communication and documents
That is great for your team, but I don’t think that your team has a size large enough to have any kind of statistically relevance at all. So it is a great example for a specific use case but not an argument for general use at all.
Yes and YYYY-MM-DD can potentially be interpreted as YYYY-DD-MM. So that is an zero argument.
No country uses “year day month” ordered dates as standard. "Month day year, " on the other, hand has huge use. It’s the conventions that cause the potential for ambiguity and confusion.
That is great for your team, but I don’t think that your team has a size large enough to have any kind of statistically relevance at all. So it is a great example for a specific use case but not an argument for general use at all.
Entire countries, like China, Japan, Korea, etc., use YYYY-MM-DD as their date standard already.
My point was that once you adjust, it actually isn’t painful to use as it first appears it could be, and has great advantages. I didn’t say there wasn’t an adjustment hurdle that many people would bawk at.
https://en.m.wikipedia.org/wiki/List_of_date_formats_by_country
Entire countries, like China, Japan, Korea, etc., use YYYY-MM-DD as their date standard already.
And every person in those countries uses YYYY-MM-DD always in their day to day communication? I really doubt that. I am sure even in those countries most people will still use short forms in different formats.
Yes, and their shorthand versions, like writing 9/4, have the same problem of being ambiguous.
You keep missing the point and moving the goal posts, so I’ll just politely exit here and wish you well. Peace.
I never moved the goalposts, all I always said was that a forced and clunky date format like YYYY-MM-DD will never find broad use or acceptance in the major population of the world. It is not made for easy day to day use.
If it sounded like I moved goalposts, that maybe due to english as a second language. Sorry for that.
But yes, I think we both have made our positions and statements clear, and there is not really a common ground for us. Not because one of us would be right or wrong but because we are not talking about the topic on the same level of abstraction. I talk about it from a social, very down to the ground perspective and you are at least 2 levels of abstraction above that. Nothing wrong with that but we just don’t see the same picture.
And yes using YYYY-MM-DD would be great, I don’t say anything against that on a general level, I just don’t ever see any chance for it used commonly.
So thank you for the great discussion and have a nice day.
For the newbies: RFC 3339 vs ISO 8601. Bookmark this site.
That looks like an interesting diagram, but the text in it renders too small to read easily on the screen I’m using, and trying to open it leads to a javascript complaint and a redirect that activates before I can click to allow javascript. If it’s yours, you might want to look in to that.
The table below works, though. Thanks for the link.
7 digit years feels way to optimistic, but I’ll be rooting for us.
NNTPS
Not sure if it counts, but the terminal world being a place where many applications do so many different things but are interoperable, is amazing. I guess that would be the POSIX standard?
The semantic web and social linked data. We could have applications share data without depending on big tech, but rather based on application standards.
It can be used today and gains traction but I wouldn’t mind it going faster. Especially the interoperable personal app space could use some love and attention.
Like with the Solid Project ?
Exactly. The Semantic Web is broader than Solid but Solid is great for personal apps.
Say you buy a smartphone. The specifications of the smartphone likely belong elsewhere than in a Solid Personal Online Datastore, but they can be pulled in from semantic data on the product website. Your own proof of purchase is a great candidate for a Solid POD, as is the trace of any repairs made to it.
These technologies are great to cross the barriers between applications. If we’d embrace this, it would be trivial to find the screen protector matching your exact smartphone because we’d have an identifier to discover its type and specifications. Heck, any product search would be easier if you could combine sources and compare with what you already have.
The sharing tech exists. Building apps works also. Interpreting the information without building a dedicated interface seems lacking for laymen.
djot for text markup. It addresses a lot of the issues in Common mark (and of course far more of the issues of Markdown).
I wish there was a good open standard for task management or todo list.
I know there’s todo.txt, but it lacks features like dependent tasks, and overall the plain text format limits features and implementations.
Do you know if it allows dependent tasks?
Yes, but not all clients expose dependent tasks (which is sadly a common issue with open standards: they aren’t always properly implemented). I’m using Tasks.org on my phone (which supports dependent tasks), synchronizing to a Nextcloud server with the Tasks app (which supports dependent tasks now, but didn’t for a long time), which also syncs to Thunderbird (which does not appear to show dependent tasks as dependents).
Well that’s still good news that I didn’t expect! I suppose I will look into that then. Thank you!
PGP or GPG, however you spell it. You can encrypt stuff, protect your email from prying eyes!
Also FOSS in general.
The tooling around it needs to be brought up to snuff. It seems like it hasn’t evolved much in the last 20+ years.
I had a small team make an attempt to use it at work. Our conclusion was that it was too clunky. Email plugins would fool you into thinking it was encrypted when it wasn’t. When it did encrypt, the result wasn’t consistently readable by plugins on the receiving end. The most consistent method was to write a plaintext doc, encrypt it, and attach the encrypted version to the email. Also, key servers are setup by amateurs who maintain them in their spare time, and aren’t very reliable.
One of the more useful things we could do is have developers sign their git commits. GitHub can verify the signature using a similar setup to SSH keys.
It’s also possible to use TLS in a web of trust way, but the tooling around it doesn’t make it easy.
The metric system, f*ck the imperial system. Every scientist sticks to the metric system, and why are people even still having an imperial system, with outdated measurements like stones for weight blows my mind.
Also f*ck Fahrenheit, we have Celsius and Kalvin for that, we don’t need another hard to convert temperature measurement.
Imperial is used in thermodynamics industries because the calculations work out better.
I’ll fight you on fahrenheit. It’s very good for weather reporting. 0° being “very cold” and 100° being “very hot” is intuitive.
Ask someone in the north of finland how hot is “very hot”, and how cold is very cold. Then ask the same in middle Africa. Spoiler: it will vary alot.
0 degrees Celsius, the water is freezing, 100 degrees Celsius, the water is boiling. Celsius has a direct link to Kelvin, and Kelvin is the SI unit for measurement temperatures.
What do I care about water? I’m not dressing water for the weather, I’m dressing me.
Are you not made primarily of water?
Asterisk: At 1 atmosphere of pressure. Lots of people forget that part.
For traffic Celsius is more intuitive since temps approaching zero means slippery roads.
You’re long passed that with Fahrenheit. And on a scale from 0 very cold to 100 very hot, 32 doesn’t seem that cold. Until you see the snow outside.
32 isn’t that cold, even if it’s snowing. I do currently live in Minnesota though, so my sense of temperature is much different than someone from somewhere warm.
my sense of temperature is much different than someone from somewhere warm
That’s probably the reason for this preference.
10°C for me means my PC doesn’t heat up the room enough and I need a heater. 32°F and I will be shoving my feet in the heater.
Minnesotan here. Can confirm that 32 is still long-sleeve shirt weather.
I regularly see people here walking into a store from the parking lot in T-shirts, in 32° weather. Wind chill makes a far greater difference. 38° from wind chill is far colder than 32° with no wind.
0° being “very cold” and 100° being “very hot” is intuitive.
As someone who’s not used to Fahrenheit I can tell you there’s nothing intuitive about it. How cold is “very cold” exactly? How hot is “very hot” exactly? Without clear references all the numbers in between are meaningless, which is exactly how I perceive any number in Fahrenfeit. Intuitive means that without knowing I should have an intuitive perception, but really there’s nothing to go on. I guess from your description 50°F should mean it’s comfortable? Does that mean I can go out in shorts and a t-shirt? It all seems guesswork.
About the only useful thing I see is that 100 Fahrenheit is about body temperature. Yeah, that’s about the only nice thing I can say about Fahrenheit. All temperature scales are arbitrary, but since our environment is full of water, one tied to the phase changes of water around the atmospheric pressure the vast majority of people experience just makes more sense.
All temperature scales are arbitrary, but since our environment is full of water, one tied to the phase changes of water around the atmospheric pressure the vast majority of people experience just makes more sense.
But when it comes to weather, the boiling point of water is not a meaningful point of reference.
I suppose I’m biased since I grew up in an area where 0-100°F was roughly the actual temperature range over the course of a year. It was newsworthy when we dropped below zero or rose above 100. It was a scale everybody understood intuitively because it aligned with our lived experience.
Ours is around 10°C to 40°C, or 15°C to 30°C depending upon your tolerances, so I guess that’s it.
And whats the difference by using -22c to 40C? Not a nice ratio? If you grew up with Celsius, you wouldnt never felt something is amiss and just feel just as natural.
This is strictly untrue for many climates. Where I live in Canada, 0F is average winter day, 100F is record-breaking “I might actually die” levels of heat.
-30C to 30C is not any more complicated or less intuitive than -22F to 86F
Knowing whether it may snow or rain depending on whether you are below or above 0 is very useful though. 0 and 100 are only intuitive because you’re used to those numbers. -20 bring very cold and 40 being very hot is just as easy.
Also f*ck Fahrenheit, we have Celsius and Kalvin for that,
Who is Kalvin? Did you mean kelvin?
One drawback of celsius/centigrade is that its degrees are so coarse that weather reporting ends up either inaccurate or complicated by floating point numbers. I’m on board with using it, but I won’t pretend it’s strictly superior.
A degree Celsius is not coarse and does not require decimals in weather reports, and I suspect only a person who has never lived in a Celsius-using country could make such silly claims.
A degree Celsius is not coarse and does not require decimals
Consider that even if the difference between 15° and 16°C is not significant to you, it very well might be to other people. (Spoiler: it is.)
I suspect only a person who has never lived in a Celsius-using country could make such silly claims.
Then your suspicions are leading you astray.
They didn’t say a difference of 1K isn’t significant but the difference of 0.1K isn’t.
And since the supposed advantage of Fahrenheit is that it better reflects typical ambient temperatures, we have to consider relevance for average people. Hardly anyone will feel a difference of 0.1K.
That’s why European weather reports usually show full degrees. And also our fridges show full degrees.
What about thermostats for homes? I can absolutely feel a 2 deg F difference
I use °C and I feel the need to use the places after the decimal. Also, I feel nothing wrong about it.
Also, I use °F for body temperature measurement and need to use the places after the decimal and feel fine with it.
Also, when using °C for body temperature, I still require the same number of decimal places as I require for °F.
I am not saying that °F is not useful, but I am invalidating your argument.
Also whole degrees. A difference of 2 °F is 1.1 °C…
You are allowed to say fuck here.
I’d like something akin to XML DOM for config files, but not XML.
The one benefit of binary config (like the Windows Registry) is that you can make a change programmatically without too many hoops. With text files, you have a couple of choices for programmatic changes:
- Don’t
- Parse it, make the change, and rewrite it (clobbering comments and whitespace that the user setup; IIRC, npm does this)
- Have some kind of block that says “things below this line were automatically set and shouldn’t be touched” (Klipper does this)
- Have a parser that understands the whole structure, including whitespace and comments, and provides an interface for modifying things in place without changing anything around it (XML DOM)
That last one probably exists for very specific formats for very specific languages, but it’s not common. It’s a little more cumbersome to use as a programmer–anyone who has worked with XML DOM will attest to that–but it’s a lot nicer for end users.
Have you heard about KDL?
GRPC for building APIs instead of REST. Type safety makes life easier
The biggest problems with gRPC are:
- Very complicated. Way more complexity than you want in most cases.
- Depends on HTTP 2. I’ve seen people who weren’t even doing web stuff reach for gRPC, and now boom you have a web server in your stack for now reason. Compare to Thrift which properly separates out encodings, transports, etc.
- Doesn’t work from the web. There are actually two modifications to gRPC to make it work on the web which means you have three different incompatible versions of gRPC with different feature sets. IIRC some of them require setting up complex proxies, some don’t support streaming calls, ugh. Total mess.
Plain HTTP can be type safe. Just publish JSON schema or Typespec files or even use Protobuf.
Your concerns are all valid, but about 1 and 3 there are possible solutions. I’m using Rust+Tonic to build an API and that’s eliminate the necessity of proxies and it’s very simple to use.
I know that it don’t solve all problems, but IMHO is a question of adoption. Easier told will be develop for it.
Depends on HTTP 2.
Doesn’t work from the web.
Am I the only one who is weirded out? How expensive do people want to make their deployments?
It’s the recommended approach to replace WCF which was deprecated after .NET framework 4.8. My company is just now getting around to ripping out all their WCF stuff and putting in gRPC. REST interfaces were always a non-starter because of how “heavyweight” they were for our use case (data collection from industrial devices which are themselves data collectors).
I like the concept and I think the use case is almost covered by generating API client through generated OpenAPI spec.
It’s needs a bit of setup but a client library can be built whenever a backend server is built.
I mean, REST-ful JSON APIs can be perfectly type-safe, if their developers actually take care to make them that way. And the self-descriptive nature of JSON is arguably a benefit in really large public-facing APIs. But yeah, gRPC forces a certain amount of type-safety and version control, and gRPC with protobuf is SUCH a pleasure to work with.
Give it time, though, it’s definitely gaining traction.
(Holocene or) Human Era calendar
That would represent all human history as one.
That sounds interesting, would most likely not be very popular with lots of people and a pain in the butt to implement but interesting.
There’s a cool video from In a Nutshell about it some years ago.
And also, the Dekatrian calendar
Where we would have a less broken, more regular, year calendar that is almost align with the moon cycle.
Oh many years ago in school I created something like that for an arts/creative writing project once, a calendar with 12, 30 day month based on sailor moon. Having it based on a magical girl manga gave me the freedom to declare the rest of the days to “days of evil” Was a fun project because I created a whole religion around it. 😁
IRC.
Jabber.
IPFS.
I also pick this guy’s IRC
IPv6. Stop engineering IoT junk on single-stack IPv4, you dipshits.
Ogg Opus. It’s superior to everything in every way. It’s free and there is absolutely no reason to not support it. It blows my mind that MPEG 1.0 Layer III is still so dominant.
IPv6. Stop engineering IoT junk on single-stack IPv4, you dipshits.
Amen
It blows my mind that MPEG 1.0 Layer III is still so dominant.
Count the number of devices in use today that will never support Opus, and it might not blow your mind any longer. Also, AFAIK, the reference implementation still doesn’t implement full functionality on hardware that lacks a floating point unit.
These things take time.
I remember using Xiph’s integer implementation of Ogg Vorbis on my Nokia N-Gage (Symbian S60). I wonder if it’s not a priority for Opus. IIRC, Opus is floats all the way down.
update: it exists.
https://wiki.xiph.org/OpusFAQ#Is_there_a_fixed-point_implementation?
Out of curiosity, why ogg as opposed to other containers? What advantages does it have?
Definitely agree on the Opus part, but I am very ignorant on the ogg container.
Large ISPs still don’t support it. It’s a fucking travesty.
Org-mode is like md but has tables and more. Emacs will even run computation as a party of interpretation. GitHub accepts it in place of markdown.
Would you say it’s worth considering in place of markdown for a non-emacs user? (I am curious to try emacs but I may not get to it anytime soon)
org-mode is awesome for many reasons, but the similarities/overlap with markdown are an incidental benefit. I wouldn’t learn org-mode for that reason, however there are many other good ones that make it worthwhile. I’ve been using it for years for my own project management, tasks tracking, notes and many other things - it’s one of those rare tools that can do many things incredibly well.
I can’t say that it is, no.
Haha appreciate the honesty :)
I do recommend emacs though. It is not the greatest editor, but it is an amazing experience. It is such an amazing experiment, that has an extensive set of different ways of looking at content and code - it will change how you think about coding.
Zigbee or really any Bluetooth alternative.
Bluetooth is a poorly engineered protocol. It jumps around the spectrum while transmitting, which makes it difficult and power intensive for bluetooth receivers to track.
I agree Bluetooth (at least Bluetooth Classic) is not very well designed, but not because of frequency hopping. That improves robustness and I don’t see why it would cost any more power. The hopping pattern is deterministic. Receivers know in advance which frequency to hop to.
