Install tzdb on provided.al2023 runtime so that TimeZoneInfo.FindSystemTimeZoneById() works

[martincostello]

Describe the feature

Logging this here as it's .NET-specific, so if not implemented for provided.al2023, it might be something desired for any forthcoming .NET 8 managed runtime.

I migrated a .NET 8 application using the provided.al2 runtime which uses the TimeZoneInfo.FindSystemTimeZoneById() method to convert UTC times to a specific time zone to provided.al2023 earlier this week, and have discovered that compared to the previous version of the provided runtime, tzdb is not installed. Calling the TimeZoneInfo.GetSystemTimeZones() method returns 0 items as well.

This causes code paths using built-in .NET time zone handling APIs that typically work outside of the Lambda runtime environment (e.g. Linux build agents, developers' Windows machines) to fail when deployed to AWS Lambda.

To fix the functionality in the application, I've had to re-introduce a dependency on NodaTime (we used to use this, but removed it in favour of the new TimeProvider API).

+ using NodaTime;

var utcNow = TimeProvider.System.GetUtcNow();
- var timeZone = TimeZoneInfo.FindSystemTimeZoneById("Europe/London");
- var localNow = TimeZoneInfo.ConvertTimeFromUtc(utcNow, timeZone);
+ var timeZone = DateTimeZoneProviders.Tzdb["Europe/London"];
+ var localNow = Instant.FromDateTimeUtc(utcNow).InZone(timeZone).ToDateTimeUnspecified();

Use Case

The application converts times in UTC to a specific time zone. For example:

var utcNow = TimeProvider.System.GetUtcNow();
var timeZone = TimeZoneInfo.FindSystemTimeZoneById("Europe/London");
var nowLocal = TimeZoneInfo.ConvertTimeFromUtc(utcNow, timeZone);

With tzdb installed, this code will work correctly.

Without it, an exception is thrown at runtime:

System.TimeZoneNotFoundException: The time zone ID 'Europe/London' was not found on the local computer.
 ---> System.IO.DirectoryNotFoundException: Could not find a part of the path '/usr/share/zoneinfo/Europe/London'.
   at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirError)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode, Boolean failForSymlink, Boolean& wasSymlink, Func`4 createOpenException)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, UnixFileMode openPermissions, Int64& fileLength, UnixFileMode& filePermissions, Boolean failForSymlink, Boolean& wasSymlink, Func`4 createOpenException)
   at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
   at System.TimeZoneInfo.ReadAllBytesFromSeekableNonZeroSizeFile(String path, Int32 maxFileSize)
   at System.TimeZoneInfo.TryGetTimeZoneFromLocalMachineCore(String id, TimeZoneInfo& value, Exception& e)
   --- End of inner exception stack trace ---
   at System.TimeZoneInfo.FindSystemTimeZoneById(String id)

Proposed Solution

Install tzdb on the provided.al2023 runtime (or the managed .NET 8 runtime if/when it becomes available).

As well as making the code functional as with provided.al2, it removes the need to include NodaTime in the function's deployment package.

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS .NET SDK and/or Package version used

The provided.al2023 runtime.

Targeted .NET Platform

.NET 8

Operating System and version

Amazon Linux 2023

[ashishdhingra]

Needs review with the team.

[normj]

Hi @martincostello, the Lambda team is aware of this issue and we are waiting on them for guidance on how they want to address the lack TZData since this is an issue that affects multiple runtimes based on AL2023.

[normj]

The OCI image for provided.al2023 has been updated to have TZData installed. It will take a couple weeks for the deployment to propagated to the provided.al2023 managed runtime.

[martincostello]

Amazing - thanks!

[mbp]

Tested today in eu-north-1. The change did not propagate to this region yet. Will try again next week.

[jonas-pietzsch]

AWS support replied to our org regarding this topic. No deep insights, basically just confirming what was written here. I'm a bit confused by the lack of transparence regarding this case.

Please note that the OCI image for provided.al2023 has been updated to have TZData installed. It will take a couple weeks for the deployment to propagated to the provided.al2023 managed runtime [1].

Whereas [1] is a reference to this issue 😆

[martincostello]

@normj Are you able to give us a minimum version number where we should see this change from so we can keep a look out for the change propagating to our app?

Running the following below on my laptop I get the following:

docker pull amazonlinux:2023
docker run -it amazonlinux:2023 /bin/bash
bash-5.2# rpm --query system-release
system-release-2023.3.20231218-0.amzn2023.noarch
bash-5.2# ls /usr/share/zoneinfo
Africa      Brazil   EST      GB         HST       Japan      NZ       Portugal   UTC                leapseconds
America     CET      EST5EDT  GB-Eire    Hongkong  Kwajalein  NZ-CHAT  ROC        Universal          posix
Antarctica  CST6CDT  Egypt    GMT        Iceland   Libya      Navajo   ROK        W-SU               posixrules
Arctic      Canada   Eire     GMT+0      Indian    MET        PRC      Singapore  WET                right
Asia        Chile    Etc      GMT-0      Iran      MST        PST8PDT  Turkey     Zulu               tzdata.zi
Atlantic    Cuba     Europe   GMT0       Israel    MST7MDT    Pacific  UCT        iso3166.tab        zone.tab
Australia   EET      Factory  Greenwich  Jamaica   Mexico     Poland   US         leap-seconds.list  zone1970.tab

Running the equivalent commands in Lambda in eu-west-1 just now I get system-release-2023.2.20231030-1.amzn2023.noarch and /usr/share/zoneinfo does not exist.

[normj]

@jonas-pietzsch Sorry you are disappointed by the lack of transparency. It isn't that I'm holding anything back I'm just pretty removed from the team that handle deployments so I don't know the schedule very well. I mostly pay attention to the .NET managed runtime deployments 😄.

I did hear there were no feature deployments over the holidays so unfortunately getting this change deployed to the provided.al2023 managed runtime is still at the early stages.

@martincostello Sorry I'm not sure on the version number.

[mbp]

Tested today in eu-north-1. Finally it works.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[Bhutania]

@normj I am still seeing this issue with the runtime: system-release-2023.2.20231030-1.amzn2023.noarch when testing on us-west-2. I know you mentioned that you are pretty removed from this process but any chance you know when the version will be released globally?

[normj]

@Bhutania Lambda deployments happen in waves across all of the AWS regions with plenty of time for each wave to monitor to make sure everything went well before moving on to the next. I'm not sure when they will get to us-west-2 but the pipeline is continuing to go along.

[Bhutania]

us-west-2 now shows system-release-2023.3.20231218-0.amzn2023.noarch as the provided-al2023 runtime.

[martincostello]

Seeing system-release-2023.3.20231218-0.amzn2023.noarch for 2 applications in eu-west-1 now too.