On 2019-12-13 15:13, Clive D.W. Feather wrote:
I don't disagree with you. The problem is that the original standards were mostly written by US people who assume that the whole world works their way. Where there's a clean sheet to start from, we can do better things [1], but that's a lot harder with a large installed base.
Is anyone aware of any plans to backport C++ work on chrono, date, tz, calendar, etc. APIs to POSIX and/or C?
The US-centric problem isn't new to this. I've lost count how many web sites can't cope with the fact that I don't have a zip code or that I have two middle initials, not one. I'm lucky that I don't have any non-ASCII characters in my name; there's a whole nother minefield waiting there.
Allow me to point you at: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-na... https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/ https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-abo... https://wiesmann.codiferes.net/wordpress/?p=15187&lang=en
Comprehensive list of lists: https://github.com/kdeldycke/awesome-falsehood
[1] For example, I've ensured that the Bluetooth Mesh standard uses TAI internally for all timestamps, leaving the leap second mess to the periphery.
How does TAI get set given that mostly UTC is distributed and LS need to be added to get TAI? Or do you mean an arbitrary TAI timescale ignoring LS? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.