time.el, world-clock default Calcutta/Kolkata?

time.el, world-clock default Calcutta/Kolkata?

[Gijs Hillenius]

Hello

time.el defines

(defcustom zoneinfo-style-world-list
  '(("America/Los_Angeles" "Seattle")
    ("America/New_York" "New York")
    ("Europe/London" "London")
    ("Europe/Paris" "Paris")
    ("Asia/Calcutta" "Bangalore")
    ("Asia/Tokyo" "Tokyo"))

Which for me has been returning the wrong response for Bangalore. This
is because in Debian (Testing and Unstable versions), tzdata no longer
recognises Calcutta. That was the official name until 2001, it is now
Kolkata, and earlier this year Calcutta was removed from tzdata, 

I can easily fix this by installing Debian's tzdata-legacy.

Alternatively, should time.el be modified to define ("Asia/Calcutta"
"Bangalore")?

Kind greetings

Gijs

Re: time.el, world-clock default Calcutta/Kolkata?

[Eli Zaretskii]

> From: Gijs Hillenius <gijs@hillenius.net>
> Date: Wed, 07 Aug 2024 20:59:51 +0200
> 
> Hello
> 
> time.el defines
> 
> (defcustom zoneinfo-style-world-list
>   '(("America/Los_Angeles" "Seattle")
>     ("America/New_York" "New York")
>     ("Europe/London" "London")
>     ("Europe/Paris" "Paris")
>     ("Asia/Calcutta" "Bangalore")
>     ("Asia/Tokyo" "Tokyo"))
> 
> Which for me has been returning the wrong response for Bangalore. This
> is because in Debian (Testing and Unstable versions), tzdata no longer
> recognises Calcutta. That was the official name until 2001, it is now
> Kolkata, and earlier this year Calcutta was removed from tzdata, 
> 
> I can easily fix this by installing Debian's tzdata-legacy.
> 
> Alternatively, should time.el be modified to define ("Asia/Calcutta"
> "Bangalore")?

You mean, ("Asia/Kolkata" "Bangalore"), right?

We cannot do that unconditionally, I think, because that would screw
systems where tzdata still has Calcutta.  If we can detect failure to
find a time zone, then maybe adding some fallback mechanism to
world-clock is the way forward, so that we could try one of the
alternatives and fall back to the other if that fails.

Or maybe we should replace that entry with some other Indian time
zone, which is less controversial?  After all, it's just the default
value of a defcustom.

Paul, any other suggestions?

Re: time.el, world-clock default Calcutta/Kolkata?

[Paul Eggert]

On 2024-08-07 22:04, Eli Zaretskii wrote:
> You mean, ("Asia/Kolkata" "Bangalore"), right?
> 
> We cannot do that unconditionally, I think, because that would screw
> systems where tzdata still has Calcutta.

Ordinarly TZDB has both Asia/Kolkata (the standard name) and 
Asia/Calcutta (the backward-compatibility alias). Although the aliases 
are normally present, they are optional. It's safe to change time.el to 
use Asia/Kolkata now, as the standard name changed in 2008 and even 
ancient systems keep up with TZDB in order to function properly. So I 
installed that change into Emacs master.

Re: time.el, world-clock default Calcutta/Kolkata?

[Stefan Kangas]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Ordinarly TZDB has both Asia/Kolkata (the standard name) and
> Asia/Calcutta (the backward-compatibility alias). Although the aliases
> are normally present, they are optional. It's safe to change time.el to
> use Asia/Kolkata now, as the standard name changed in 2008 and even
> ancient systems keep up with TZDB in order to function properly. So I
> installed that change into Emacs master.

Shouldn't that fix be installed on emacs-30?

Re: time.el, world-clock default Calcutta/Kolkata?

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 9 Aug 2024 08:41:20 +0000
> Cc: emacs-devel@gnu.org
> 
> Paul Eggert <eggert@cs.ucla.edu> writes:
> 
> > Ordinarly TZDB has both Asia/Kolkata (the standard name) and
> > Asia/Calcutta (the backward-compatibility alias). Although the aliases
> > are normally present, they are optional. It's safe to change time.el to
> > use Asia/Kolkata now, as the standard name changed in 2008 and even
> > ancient systems keep up with TZDB in order to function properly. So I
> > installed that change into Emacs master.
> 
> Shouldn't that fix be installed on emacs-30?

It isn't urgent enough for that, IMO.