Closed zengzhenbo closed 2 years ago
Actually now that I think about it, it only makes sense to convert to a local time in the browser because server's time zone may or may not be local.
Using UTC time on servers is the only sane thing to do, too.
Got it.
Not so fast ;) There is also a problem with inferring the correct state of queue. In my case idle_since is 2 hours before the local time so queue is always shown in idle state which is not true. This is very misleading. Fix probably should be made somewhere in javascript.
Any update on this ?
No updates and no plans to prioritize this any time soon. Community contributions would be considered, this is open source software after all.
This issue can be closed, see https://github.com/rabbitmq/rabbitmq-server/pull/4331
In the file rabbit_mgmt_format.erl
now_to_str(unknown) ->
unknown;
now_to_str(MilliSeconds) ->
BaseDate = calendar:datetime_to_gregorian_seconds({{1970, 1, 1},
{0, 0, 0}}),
Seconds = BaseDate + (MilliSeconds div 1000),
{{Y, M, D}, {H, Min, S}} = calendar:gregorian_seconds_to_datetime(Seconds),
print("~w-~2.2.0w-~2.2.0w ~w:~2.2.0w:~2.2.0w", [Y, M, D, H, Min, S]).
the result of now_to_str/1 is UTC time, and these times will be showed on the management ui, users may misunderstand these time. now_to_str/1 should converts from UTC to local time by call calendar:universal_time_to_local_time/1 before print/1