[zigzag312]

Author states:

>And that’s the point, rules and complexity have completely unknowable downsides. Downsides like the destruction of the whole project. With each rule and added complexity you make the system less human and less fun. You make it a Computer Scientists rube goldberg machine while sterilizing it of all the joy of life.

While too much rules and complexity can certainly be bad, some basic amount of standardization can actually reduce complexity and really doesn't cause a "destruction of the whole project".

As a counterpoint, too much flexibility can also increase complexity. For example, without defined rules, 5.6.2022 can mean 5. June 2022 or 6. May 2022. Nor user, nor parser can know for sure what it means, if standard isn't defined. This kind of flexibility certainly isn't fun.

Example from OSM wiki for "Key:source:date":

> There is no standing recommendation as to the date format to be used. However, the international standard ISO 8601 appears to be followed by 9 of the top 10 values for this tag. The ISO 8601 basic date format is YYYY-MM-DD. https://wiki.openstreetmap.org/wiki/Key:source:date

Just define some essential standards. It won't lead to destruction of the project!

And while you are making breaking changes, please fix the 'way' element. Maps are big. Storing points in ways as 64bit node-ids, while coordinates in nodes are also 64-bit (32bit lon and 32bit lat), just leads to wasted space and wasted processing time. There are billions of these nodes and nearly all of these nodes don't have tags, just coordinates. There is no upside for this level of indirection. And in case tags are needed for a point, this can already be solved with a separate node and a 'relation' element.

OSM data format could certainly be improved and it would benefit end users, as better tools/apps could be made more quickly and easily.

[atoav]

The date example is a good one. No one has fun by choosing their own date format. This is putting the burden of choice onto the user. They might like to think about some map stuff and now they have to think about data format stuff.

Of course projects like these have to strike a balance between the strictest bureaucratic nightmare and such a structure so loose that people are overburdened by the available options at every corner.

I think a lot of that complexity can (and should!) live in the tools themselves. Who cares about a date format, when the tool that creates it offers a date picker or extracts the correct date from the meta data of an image? The date format in the backend should be fixed and then you should offer flexibility in the frontend for user input.

[Archelaos]

> The date format in the backend should be fixed and then you should offer flexibility in the frontend for user input.

Agreed. However, it might be not so easy for historical dates, because doing it correctly requires great diligence on the part of the tool developer as well as from the user to choose the correct calendar system. For example:

  Q: What is the correct representation of the date of Caesar's death, 15 March 44 BC in ISO-8601?

  A: -0043-03-13

  Why? -- Ancient dates are typically given according to the Julian calendar excluding a year 0, but ISO-8601 uses a proleptic Gregorian calendar including a year 0.

[nvrspyx]

This is a good point in a general sense, but I don't think it would be a problem in this particular case for the date some imported OSM data was sourced, which is similar to the "date accessed" for a website in a bibliography.

[Archelaos]

I had the Open Historical Map sub-project in mind, which currently supports only ISO-8601.[1]

[1] https://wiki.openstreetmap.org/wiki/Open_Historical_Map/Tags...

[netsharc]

In Java and Javascript, months are 0-based, so October is 9. Geez, imagine forcing people to write "October 15, 2019" as "2019-09-15"

[Archelaos]

Yeah, as it already is an imposition to use 10 for what is called "Month Eight" (from Lat.: octo = 8).

[BitwiseFool]

Glad to hear I'm not the only one. A switch flipped in my brain once I realized this and now I routinely mix up October and August.

Would it really have been too much to ask that July and August come after December?!

[Archelaos]

  Q: Why do software engineers confuse Halloween and Christmas?
  A: Because Oct. 31 = Dec. 25

[sorokod]

July was renamed away from Quintilis ( the fifth month of the Roman calendar )

So yes, a bit much.

[atoav]

I am one of those guys who use ISO 8601 for everything. It just makes the most sense to me. But I would not force ot onto my users.

[joshxyz]

why not use the universal date format [1] that works for everyone?

yyyy mm dd mm yyyy

[1] https://twitter.com/dan_abramov/status/1447710863960551433

[Grimburger]

Unix time is the real universal date format surely? It underpins basically everything in datetime database entries.

The problem is that most people can't read that along with the French somehow never being able to convince the world to adopt decimal time.

[deathanatos]

> Unix time is the real universal date format surely?

Heh… It can't represent UTC (leap seconds). Implementation weirdness like not being able to represent dates outside the 32-bit second counter range due to using a 32-bit second counter. The occasional need to store the TZ the timestamp is relevant in/to.

> It underpins basically everything in datetime database entries.

It does do that.

> The problem is that most people can't read that

This is why I prefer RFC 3339 or ISO, in that order.

> along with the French somehow never being able to convince the world to adopt decimal time.

Somehow. :)

[shagie]

As much as it is maligned, base 60 is rather convenient. It's easy to take 1/2, 1/3, 1/4, 1/5 and 1/6th of that number. Base 12 has this property too (though lacks the easy 1/5th).

[m463]

> Unix time is the real universal date format surely?

maybe in space, but 2038 will have an interesting time warp.

[extropy]

Only for the ones trying to write it down as 32 bit signed int.

Nothing wrong with the format itself.

[lovemenot]

Why make a good point and follow it with a bad joke which: both has a class of victim and does not work as a joke?

Nobody has ever heard of "the French" undertaking such a project. And if it had ever happened, it would most surely have been a particular Academy or the like. Not the 65M people under your careless swipe.

[deathanatos]

https://en.wikipedia.org/wiki/Decimal_time#France

[misnome]

Along with most of the metric system, which they did somehow manage to persuade the rest of the world to use.

[Grimburger]

I'm actually one of those weird folks who likes decimal time and maybe one day we'll get there given that every other metric system was adopted by engineers worldwide except for time.

Wasn't meant as some slight against the French, completely the opposite hey, honestly think they had the right idea, the rest of the world got it wrong...and... that's very much a minority opinion these days. Some things are just ingrained into everyone I guess.

[pbronez]

French Revolution came up with some wild shit and some truly excellent ideas. That’s a season of change for ya… high variance.

[RcouF1uZ4gsC]

It actually doesn't work for Americans who write:

mm dd yyyy

[magicalhippo]

Trivially fixed by using mm dd yyyy mm dd mm yyyy.

[867-5309]

you'll have to round up those 86,400ths!