A fork for the time-zone database?

Posted Sep 29, 2021 8:32 UTC (Wed) by dveeden (subscriber, #120424)
In reply to: A fork for the time-zone database? by tux3
Parent article: A fork for the time-zone database?

According to https://bodhi.fedoraproject.org/updates/FEDORA-2021-b3ed2... it looks like Fedora isn't going to cherry-pick

A fork for the time-zone database?

Posted Sep 29, 2021 8:54 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (4 responses)

That will only work till the change hits RHEL and @rh customers start complaining (especially government RH customers that won’t take the relocation in another country lightly).

It is incredibly offensive to merge different political entities from outside. That some could not defend themselves in the past does not mean others won’t. Moreso because of some (primarily US) political agitation not shared in other countries (which have their own political issues to tackle).

Leveling down has never been a road to success.

A fork for the time-zone database?

Posted Sep 29, 2021 19:07 UTC (Wed) by fuhchee (guest, #40059) [Link] (2 responses)

Perhaps some view equity as more important than success.

A fork for the time-zone database?

Posted Oct 10, 2021 6:13 UTC (Sun) by rlhamil (guest, #6472) [Link] (1 responses)

Then add more separate historically accurate data for the under-served rather than removing usual access, if not the data itself, for the supposedly over-served.

That would strive for both accuracy and balance; genuine "equity" should not reduce accuracy for anyone.

A fork for the time-zone database?

Posted Oct 10, 2021 17:57 UTC (Sun) by Wol (subscriber, #4433) [Link]

I'm personally thinking, separate the master database from the active one.

Why has he gone for 1970? Okay, that may be the Unix base date, but why is he dragging Unix history into this? Surely the number of people who care about going back to 2010 are pretty much the same as those who care about going back to 1970. By his logic we might as well decide to go back only a decade.

MOST people don't give a monkeys about historic data. Some people need to be able to go back a year or two. Others need to go back as far as possible.

Just make it easy, at the user level, to generate the active database from the master. Then we don't care about detail too much in the active database, but we care strongly about accuracy in the master.

Cheers,
Wol

A fork for the time-zone database?

Posted Sep 30, 2021 6:41 UTC (Thu) by cpitrat (subscriber, #116459) [Link]

The fix is easy: those countries need to change their timezone to be different, just for the sake of being different.

A fork for the time-zone database?

Posted Sep 30, 2021 6:03 UTC (Thu) by dvdeug (guest, #10998) [Link]

As of today, Debian unstable isn't going to cherry-pick either.