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

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Sat Dec 14 06:20:39 UTC 2019

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:

> [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.

More information about the tz mailing list