Did not exist in Intl.DateTimeFormat

Did not exist in Intl.DateTimeFormat

I'm not sure how to get this available for your tests. When I ssh-ed into ray head, I saw tzlocal, so I think it's available normally, but your tests were failing with not being able to find tzlocal. I could use some help pointing to how to get the tests happy as I'm otherwise just skimming through the codebase and guessing.

why this get_current_timezone_info is required in the first place? for frontend ui, it should either use browser time or use utc, right? why does server side local timezone even matter?

I did not implement this feature of yours. I'm trying to fix that the feature doesn't work. If you would rather drop the server timezone and just use the browser's time zone, that's fine by me.

yeah, I am more of asking the component owner.

The default option is to use server timestamp because that is the timestamp that is printed to the log files.

We provide an option to use the browser timestamp for convenience, but that will not update the timestamp already printed to logs, which will be confusing.

The Ray Dashboard does not parse any logs today. It just prints them as raw text.

I think the simplest approach would be if we used UTC everywhere, but I'm not sure if that's the behavior everyone wants.

A quick fix to the issue at hand would be to drop the timezone names from the UI and only show offset numbers in the dropdown.

and I am not a fan of this new dependency..

Can you say more on why? It's already a dependency of yours.

it is not ray dependency, it is a dependency of anyscale CLI, which is currently required to be built into the ray release test image to run ray release tests, which is why we added in the dependency resolving procedure and pinning the version for CI/CD. ray does not depend on tzlocal. if you pip install ray[all] on an empty python virtual env today, tzlocal will not be installed.

Ok, if you don't want to use tzlocal other options I see:

• Drop server time (your previous question). Note in terms of use cases, a remote worker in a different time zone might like using server time zone (though I'm sure that remote worker experiences issues related to this in 200 other places besides the ray dashboard).
• Shortcut it and just use os.environ["TZ"] (which skips the full resolution of going to /etc/timezone that tzlocal does, as I don't want to duplicate what an off the shelf thing does).
• Try and mirror what the typescript side does - e.g. have a "preferred" list of IANA tiime zones to deal with the lack of 1:1 mapping in python abbreviations:

from datetime import datetime
from zoneinfo import ZoneInfo, available_timezones

now = datetime.now()
timezone_map = {tz: now.astimezone(ZoneInfo(tz)).tzname() for tz in available_timezones()}

tz_abbreviation = now.astimezone().tzname()
possible_timezones = [timezone for timezone, abbreviation in timezone_map.items() if abbreviation == tz_abbreviation]