[tz] isdst bug Europe/Dublin (tzdb-2019c)

[Brian Inglis]

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-names/
> https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/
> https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
> 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.