[andos]

Falsehoods programmers believe about addresses [1][2] is long-overdue. “There is a current, established format for international addresses” is probably one of them.

[1] http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...

[2] http://infiniteundo.com/post/25326999628/falsehoods-programm...

[TillE]

Line 1, Line 2, Line 3, Country should cover just about all cases.

Ask yourself if you really need to break out the specific components of the address. In this case you don't. As long as the user knows the correct local format, it's fine.

[px1999]

The txt file isn't just about the user though, it's to aid in indexing useful information from the site, so having some sort of breakdown into nested administrative divisions is something that makes sense (after all, I don't just say "I'm looking for a steakhouse in the USA" when I'm trying to decide where to have dinner). Of course, administrative divisions introduce their own problems and work against the whole human readable / human writeable nature of what they're trying to achieve.

On the flipside, even Line 1, 2, 3, country isn't sufficient for all addresses. If you have an addressee, additional delivery information (eg a department), need to include a rural route identifier (eg for Canada), or need to store/use bilingual addresses (again for Canada) then you need more than 3 lines. If you want to talk edge cases, having a country code means that places like the Haskell Free Library and Opera House (http://en.wikipedia.org/wiki/Haskell_Free_Library_and_Opera_...) can't be correctly addressed.

Hell, even the Falsehoods programmers believe about time doesn't come close to capturing the intracacies of lunar/lunisolar calendars (eg those with 13 months in a year, or a variable number of months in a year etc).

I guess that my point is that you need to find the balance of utility and complexity. If you need to be able to store every format of everything you wind up with either a hugely complex schema, or a single field that contains everything (and may even not capture everything completely), but that's not useful for anything except end-user display when the user is able to parse (or make a good guess at) the data.

Unfortunately there isn't a single winning approach - so unless you draw an arbitrary line your specification can't encompass every edge case while maintaining simplicity and achieving what it's set out to.

[facorreia]

Right. What I really meant is, "a format that is not US-centric".