Run the application with a different time zone.

[EvgenyPrikhodko]

Run application in a different time zone
Problems:

1. There is no source code.
2. The project is large, written previously to rewrite using, for example, TimeZoneInfo great refactoring.
3. This is especially problematic when applications need to be run from a hosting provider (azure, amazone, etc.).
4. When the developer doesn't know the server timezone.

For example like this:
dotnet myapp.dll --timezone "Morocco Standard Time"

Optional:
This discussion was discussed here

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[danmoseley]

@tarekgh

[Gnbrkm41]

How hard is it to do timedatectl set-timezone Africa/Casablanca (*nix) or Set-TimeZone -Id "Morocco Standard Time" (Windows) before running the app, or what restricts you from doing that? Why do you want the OS Timezone to be different from the app's timezone? What about possible discrepancies between the app itself and dependencies of the app that acquire timezone / time data from other sources - e.g. native libraries that directly call into the OS?

I'm not exactly sure why this feature is required and how much value this holds, other than being (what looks to me) a hacky workaround for a specific problem that I'm unsure if it is common. Could you perhaps elaborate a bit more about your scenario?

[EvgenyPrikhodko]

How hard is it to do timedatectl set-timezone Africa/Casablanca (*nix) or Set-TimeZone -Id "Morocco Standard Time" (Windows) before running the app, or what restricts you from doing that? >

Not difficult. but in my version does not solve the problem, for example, I have other applications on the same server that may live in a different time zone

Why do you want the OS Timezone to be different from the app's timezone? >

It is very simple, take an example, hosting does not always have access to the OS, or the server uses UTC, and the application should, for example, be in utc + 3.

What about possible discrepancies between the app itself and dependencies of the app that acquire timezone / time data from other sources - e.g. native libraries that directly call into the OS?

It is understandable here, if the application uses other people's native libraries, I agree, in this case you need to solve the issue differently. Not my case

I'm not exactly sure why this feature is required and how much value this holds, other than being (what looks to me) a hacky workaround for a specific problem that I'm unsure if it is common. Could you perhaps elaborate a bit more about your scenario?

It's very simple, we have 3 web servers running asp.net Core. I needed to launch another application, but it turned out that a different time zone was needed. Moreover, this application will be launched in 5 instances in 5 different time zones. That would not buy 5 servers, this option will save money and time.
When to use a specific time zone within the same application.

[ghost]

Tagging subscribers to this area: @tarekgh, @safern, @krwq
See info in area-owners.md if you want to be subscribed.

[Clockwork-Muse]

Moreover, this application will be launched in 5 instances in 5 different time zones. That would not buy 5 servers, this option will save money and time.

If you can use Docker, you can set the timezone for the container. However....

It is very simple, take an example, hosting does not always have access to the OS, or the server uses UTC, and the application should, for example, be in utc + 3.

It's not going to help in your case (since you don't have the original source to modify), but generally the server/os/process timezone should be completely irrelevant. You want some way for your application to retrieve/use an entity timezone - it figures out what timezone it needs based on what entity it's processing, and uses that. Potentially, that means that you'd only launch one instance of the application (and definitely makes your server config easier).

Some legacy applications were definitely written assuming a specific server timezone, but modern applications should not be written that way.

[PathogenDavid]

It's worth noting that the runtime already supports the TZ environment variable on Linux:

The value of TZ can basically be any file under /usr/share/zoneinfo. (Or an absolute path to a custom timezone file.)

This functionality is implemented by TimeZoneInfo.TryGetLocalTzFile.

[tarekgh]

@PathogenDavid what is your scenario you want to use this for?

[PathogenDavid]

@tarekgh I have 0 use for this feature, I just stumbled upon the discussion and thought I'd mention TZ since it's less hacky than the reflection method as long as you don't need Windows support. (Which was seemingly the case for @EvgenyPrikhodko)

[EvgenyPrikhodko]

@tarekgh I have 0 use for this feature, I just stumbled upon the discussion and thought I'd mention TZ since it's less hacky than the reflection method as long as you don't need Windows support. (Which was seemingly the case for @EvgenyPrikhodko)

Thanks, but your solution doesn't work for me.

[PathogenDavid]

@EvgenyPrikhodko Not sure what to tell you, works fine for me on WSL.

[EvgenyPrikhodko]

@EvgenyPrikhodko Not sure what to tell you, works fine for me on WSL.

Thank you, we know this option.

[betmix-matt]

It's worth noting that the runtime already supports the TZ environment variable on Linux:

The value of TZ can basically be any file under /usr/share/zoneinfo. (Or an absolute path to a custom timezone file.)

This functionality is implemented by TimeZoneInfo.TryGetLocalTzFile.

Instead of adding a new argument to dotnet run, why not just make Windows consistent with Linux so that if the TZ environment variable is set in Windows, dotnet automatically uses that to determine the system timezone?

[tarekgh]

Instead of adding a new argument to dotnet run, why not just make Windows consistent with Linux so that if the TZ environment variable is set in Windows, dotnet automatically uses that to determine the system timezone?

This is a clever idea. The only concern with that setting such environment variable is going to affect other applications running on the same machine if the environment variable is set per user or machine. On Linux is ok as this is documented behavior for the OS. But Windows doesn't support that and can be a surprise for some applications. Maybe the best here is to do that with a config switch?

[betmix-matt]

I guess it is kinda a major change as it could technically be a breaking change. It would be really nice if you didn't have to specify a command line argument to make this work though. I hate that for every OS except windows, TZ sets the timezone. Why does windows have to be so difficult?

[tarekgh]

It would be really nice if you didn't have to specify a command line argument to make this work though.

agree.

Why does windows have to be so difficult?

Did you request that from Windows before? :-)