[NEW FEATURE] Change Timezone

[andrew-manger]

Is your feature request related to a problem? Please describe.
Logs appear in GMT.

Describe the solution you'd like
It would be nice to adjust this so logs appear in local timezone to more accurately and quickly scan logs.

Describe alternatives you've considered
Updating docker containers to local timezone, but it didn't affect it.

[mrjackwills]

Yeah, hadn't considered that.

Can you post an example of a line of logs as it currently stands, and then the same line but how you imagine it to be once the timezone is accounted for - please also let me know the timezone you are changing it into.

[andrew-manger]

Thanks for the quick response @mrjackwills!

Here are the current and desired states. I am in the America/Denver UTC-7 timezone.

Note that I changed the time/date format a bit to make it easier to read. Not necessary part of the request, but would be a nice touch! Maybe some sort of config file to choose how time/date is displayed? For example, I don't need to see that I am UTC-7, but another user might. Or the UTC shift can be tacked on to the end of the date/time. Lots of good solutions :)

Just as a note for context as well, I use generally use dockge to manage my containers at home and on the go, but the logs aren't too great so I use oxker of troubleshooting, identifying container names, verifying ports, etc.

Current

Desired

[mrjackwills]

Thanks for the quick response @mrjackwills!

Just good timing, happened to be browsing GitHub when you commented.

Will give it some thought, ideally don't want to bring in any large, but thorough, dependecies like time-tz, but hopefully it wouldn't be needed.

I haven't really looked into the Docker log timestamps, but looks like they are always UTC? In which case a simple offset cli arg could be supplied, ---timezone -8, --tz +1, --time-zone +3.5? Do you have any suggestions as to what makes sense there?

Anything with time and time zones is an easy way to make a mistake or overlook one of the many oddities, so we'd need to make sure we aren't doing anything obviously - or most likely not obviously - foolish.

[andrew-manger]

I think a cli argument would work. Ideally a config file would be easier from a user perspective since it would only have to be set once. Or if you want to change it across the board, you could apply an automatic offset based on the system time. Just brainstorming some! I’m not sure how useful this would be to other users so don’t stress too much. Definitely don’t want to bloat it with large dependencies.

[mrjackwills]

Theres another issue open that would really benefit from a config file, but I haven't got round to implemeting it yet. When done, it could encompass every cli arg and more.

I had a little play around, and we can easily automatically grab the users timezone, and then it's a simple case of applying an offset between that and UTC to the logs. The issue arises when the user is running oxker via a Docker image. These are based on scratch images, and don't have a timezone set. Two options in this case would be to either mount /etc/timezone (assuming all unix based systems have this or similar);

docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock:ro -v /etc/timezone:/etc/timezone:ro --pull=always mrjackwills/oxker

or setting a TZ env;

docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock:ro -e TZ="America/New_York" --pull=always mrjackwills/oxker

A cli arg could also be used, which would be used in any context (Docker, binary installed, installed via Cargo);

docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock:ro --pull=always mrjackwills/oxker --tz "America/New_York"

oxker --tz America/New_York

Then again, if a --tz arg is used, is it better just to use an actual number for the offset, oxker --tz -5, else we have to check that the supplied timezone is first valid, and then return it's offset from a bundled timezone db component.

[andrew-manger]

That’s interesting, I couldn’t see myself running oxker in a docker container lol, but yeah, I think the first two options are both viable and only require one line in a docker compose file. All my containers already implement the TZ environment variable.

[envp]

Then again, if a --tz arg is used, is it better just to use an actual number for the offset, oxker --tz -5, else we have to check that the supplied timezone is first valid, and then return it's offset from a bundled timezone db component.

It may be better to use the TZ Identifier if someone wants to use --tz. The numerical offset can change during daylight savings and other such events.

It could be a bother to look up identifiers if someone wants to test multiple offsets but I'm not sure how common a use that would be for oxker.

[mrjackwills]

@andrew-manger Would you be able to test this feature on macOS for me?

I can provide a binary, or if easier I can publish a branch which you should be able to build - assuming you have Rust installed.

[andrew-manger]

@mrjackwills for sure! I can do either

[mrjackwills]

Thanks, there's a branch called feat/set_tz, and hopefully this comment will have an aarch64-apple-darwin binary, compressed into a .tar.gz, attached to it.

To set a timezone, you can run oxker with the --timezone cli flag, it should work for every timezone case insensitive;

oxker --timezone ASIA/tokyo

The Docker timestamps should then be in that timezone. The help popup panel should also display which timezone is in use.

This, as yet unreleased, version of oxker also makes use of a config file. It automatically creates said file in the systems user local config directory. On macOS I think this will be at $HOME/Library/Application Support/oxker/config.toml. You can then set a timezone in that file which should automatically be applied every time you run oxker. If you could test that out for me as well it would be helpful. The config file also has many new features, custom themes etc.

oxker.tar.gz

[andrew-manger]

@mrjackwills I tested the binary with the cli flag as well as the config.toml file and they both worked beautifully! It also showed up correctly in the help panel as expected 👍🏼 are you planning on adding a config option for the timestamp format as well? I don't want to seem too particular as the timezone update is already stellar.

[mrjackwills]

Thanks, sounds good, probably have a few more tests to write, but otherwise should make a new release this week.

Being particular is fine, how would you like the timestamp to be formatted? Now that we have a config file it should be easy to add an additional setting for that.

[andrew-manger]

Nice!

The timestamp shows like this currently: 2025-02-19T16:16:24.894224899-07:00

I would want to set a config variable such as tz_format to reformat the timestamp like this (I provided two options for formatting):

format: `HH:MM:SS.NNNNN dd-mm-yyyy`
alt format: `%H:%M:%S.%5N %d-%m-%Y`
output: `16:16:24.89422 19-02-2025`

[mrjackwills]

The config file should now accept a timestamp_format for custom formatting.
It defaults to "%Y-%m-%dT%H:%M:%S.%8f", which will result in the standard formatting of 2025-02-18T12:34:56.01234567.

It should accept any valid sfrftime formatted string, and will default to the previously mentioned one if a basic parse check doesn't pass.

I have yet to write tests for it, but let me know what you think.

Again I'll attach a tar.gz to this comment, and it'll be the latest commit on the feat/set_tz branch

oxker.tar.gz

[andrew-manger]

Works like a dream!!