Support IANA time zone for date formatting

[dzonatan]

Which @angular/* package(s) are relevant/related to the feature request?

No response

Description

This was once requested #40865 but is now locked due to inactivity. I want to raise this again because IMO supporting IANA timezone names natively is a huge improvement, especially now when you can set the default timezone (which is actually an UTC offset, not a timezone) through DATE_PIPE_DEFAULT_OPTIONS token.

Why supporting IANA is such a big deal? Because of Daylight Saving Time (DST).
Countries that are using DST does not have a fixed UTC offset, it depends on the season.
So setting a default timezone (which is an UTC offset) through DATE_PIPE_DEFAULT_OPTIONS does not bring that much value today, it's even hard to think of a use case for this. For applications that let the user to set their preferred timezone in settings this token can't be utilized, you're still forced to come up with workaroundish solutions like creating a custom date pipe.

This is a default behaviour when timezone is not provided:

<!-- 
Browser timezone: Europe/Vilnius
DATE_PIPE_DEFAULT_OPTIONS: not provided
-->

{{ '2022-10-29T05:00:00.000Z' | date: 'full' }} // Thursday, 29 October 2022 at 08:00:00 GMT+03:00 ✅ 
{{ '2022-10-31T06:00:00.000Z' | date: 'full' }} // Thursday, 31 October 2022 at 08:00:00 GMT+02:00 ✅ 
<!-- As you can see DST is handled flawlessly. -->

Now imagine we want to format all dates the same for all the users not matter on what timezone they are (maybe it's a company timezone, whatever). What DATE_PIPE_DEFAULT_OPTIONS value has to be provided for this to work? UTC+2 or UTC+3 (in case of Europe/Vilnius tz)? You see, you can't choose one, both are needed depending on the date you're trying to format.

<!-- 
Browser timezone: Europe/Stockholm (does not matter, can be any tz)
DATE_PIPE_DEFAULT_OPTIONS: { timezone: 'UTC+2' }
-->

{{ '2022-10-29T05:00:00.000Z' | date: 'full' }} // Thursday, 29 October 2022 at 07:00:00 GMT+02:00 ❌ 
{{ '2022-10-31T06:00:00.000Z' | date: 'full' }} // Thursday, 31 October 2022 at 08:00:00 GMT+02:00 ✅ 

<!-- 
Browser timezone: Europe/Stockholm (does not matter, can be any tz)
DATE_PIPE_DEFAULT_OPTIONS: { timezone: 'UTC+3' }
-->

{{ '2022-10-29T05:00:00.000Z' | date: 'full' }} // Thursday, 29 October 2022 at 08:00:00 GMT+03:00 ✅ 
{{ '2022-10-31T06:00:00.000Z' | date: 'full' }} // Thursday, 31 October 2022 at 09:00:00 GMT+03:00 ❌ 

Proposed solution

Add support for IANA time zone name in all these APIs:

https://angular.io/api/common/DATE_PIPE_DEFAULT_OPTIONS

{ provide: DATE_PIPE_DEFAULT_OPTIONS, useValue: { timezone: 'Europe/Vilnius' } }

https://angular.io/api/common/formatDate

{{ myDate | date: 'full':'Europe/Vilnius' }}

https://angular.io/api/common/DatePipe

formatDate(myDate, 'full', 'Europe/Vilnius');

Alternatives considered

If for some reason IANA time zone support is not considered to be implemented now or in the future then I would suggest renaming the timezone property to utcOffset which would be more accurate and less confusing for developers.

[ghost]

Angular has dropped the intl API in v5 (2017) because of some bugs. Now it's almost 2023, IE support is not needed, intl polyfill is probably not needed? Wouldn't it be possible to switch back to the intl API as it's more stable now?

[jessicajaniuk]

We should be able to remove those IE / Edge workarounds and would welcome community contributions to fix this issue.

[surajy93]

@jessicajaniuk may I help to fixed this issue?

[jessicajaniuk]

Please do, @surajy93. We'd appreciate it.

[marklreyes]

In context to year 2023 and Angular 15+, if passing IANA value doesn't work, what is the timezone key's value supposed to be? Yes, I do see it in Documentation for DATE_PIPE_DEFAULT_OPTIONS but what is the string value to pass? Abbreviations like this?

[dzonatan]

angular/packages/common/src/i18n/format_date.ts

Line 53 in 6145cc1

* @param timezone The time zone. A time zone offset from GMT (such as `'+0430'`),

[massic80]

angular/packages/common/src/i18n/format_date.ts

Line 53 in 6145cc1

* @param timezone The time zone. A time zone offset from GMT (such as `'+0430'`),

...or

angular/packages/common/src/i18n/format_date.ts

Line 54 in 6145cc1

* or a standard UTC/GMT or continental US time zone abbreviation.

but I'm not sure what continental US time zone abbreviation means, exactly.
In particular, I'd appreciate the timezones to automatically consider summer time (as Intl does, AFAIK): Europe/Rome is CEST (UTC+2) during the summer and CET (UTC+1) during the winter.

[dzonatan]

I'd appreciate the timezones to automatically consider summer time

This is what this issue and the submitted PR is about. But the PR have been hanging for almost a year without any closure, so I no longer expect it to be merged. :)

[massic80]

I agree,,,
but what does continental US time zone abbreviation mean?.

[Vizer]

Can anybody provide some details what is the state of this issue? And what exactly wrong with related PR?
In my project this is basicly a major issue that makes DatePipe not usable at all.

[marklreyes]

It doesn't appear like this issue was prioritized and potentially won't be merged as described by the author.

Also, with the advent of Angular 17's release last November 2023, if IANA time zone support wasn't added inside of the out-of-box date pipes they support, then this is still a valid issue to keep open.

I guess before assuming DatePipe isn't usable at all, it really depends if the IANA time zone support use-case is truly needed. Is it make/break for your project? I wanted to use it because of the flexibility it has for areas of the US that didn't observe DST (e.g., Arizona, Hawaii), but found compromise (with Product Team) in the feature needed (we're simply using Standard Time offsets such as -800 for Pacific Standard Time, etc.).

I realize my case doesn't match up with yours, and I'm in all likely cases comparing apples to oranges, but I guess what I'm trying to land on is, can you use existing alternatives as a compromise for what you're trying to build out?

[JeanMeche]

We're currently investigation relying on the Intl API for date formatting. This would allow us to support IANA timezones.

Feel free to subscribe to #54470 for any updates on that topic.