Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API Support for IANA Time Zone String Redirection in FreeRDP #10112

Open
aleitner opened this issue Apr 22, 2024 · 3 comments · Fixed by #10120
Open

API Support for IANA Time Zone String Redirection in FreeRDP #10112

aleitner opened this issue Apr 22, 2024 · 3 comments · Fixed by #10120
Milestone

Comments

@aleitner
Copy link

Is your feature request related to a problem?
I am using FreeRDP version 2.11.6, and I've encountered a limitation with time zone redirection. The problem involves setting the timezone in an RDP session based on a timezone string, such as "UTC" or "Asia/Tokyo", in IANA format. While FreeRDP automatically detects and maps the local UNIX time zone to the appropriate Windows time zone, there isn't a way to pass this information from an external source, like a string, to FreeRDP directly. I have tried to set the "TZ" environment variable within my application, but it appears that FreeRDP is not reading this variable to set the timezone for the RDP session, which leads to the inability to redirect to the correct timezone based on the provided timezone string.

Describe the solution you'd like
I would like FreeRDP to support setting the ClientTimeZone through an API that accepts a timezone string in IANA format. This would allow users to set the timezone for an RDP session dynamically based on a string. Enhanced documentation that explains how to use this functionality would be a big help for others using this feature as well. The wiki article was last updated in 2012 https://github.com/FreeRDP/FreeRDP/wiki/Time-Zone-Redirection

Describe alternatives you've considered
From what I have read on other sourceforge interactions, an alternative would be to manipulate the TZ environment variable or the system-wide /etc/localtime setting, but this is not always practical or possible, especially when interfacing with remote clients through web applications.

Additional context
This feature would be particularly beneficial for web applications managing remote sessions across various time zones, ensuring accurate time settings for each user's session. A good example of such an application is Apache Guacamole, which acts as a middleman between the web client and the RDP server. Often, these applications can capture the client's timezone in IANA format, as documented here: List of tz database time zones, but they lack the ability to communicate those settings to FreeRDP.

@akallabeth
Copy link
Member

support for TZ environment variable is available in current stable 3.x releases.
oldstable 2.x will only receive security updates at this point in time.

@akallabeth akallabeth added this to the next-3.0 milestone Apr 22, 2024
@aleitner
Copy link
Author

support for TZ environment variable is available in current stable 3.x releases. oldstable 2.x will only receive security updates at this point in time.

From your comment, I understand that the 2.x version is considered oldstable and will only receive security updates, but can you confirm if the TZ environment variable has ever been recognized in any of the 2.x releases or has this always been only available with the 3.x series? Given the constraints of staying with the 2.x series, would there be a recommended method for achieving timezone redirection that incorporates IANA timezone strings?

@akallabeth akallabeth linked a pull request Apr 22, 2024 that will close this issue
@akallabeth
Copy link
Member

@aleitner 2.x did not have that feature.
I´ve just created #10120 to make this more usable on the 3.x series as well (you can now use the settings::ClientTimeZone value in command line parser or your application)

if you want that in 2.x we accept backport pull requests, but just don´t do them ourselves ;)

@akallabeth akallabeth removed a link to a pull request Apr 23, 2024
@akallabeth akallabeth linked a pull request Apr 23, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants