It is tedious and error prone to enter full names. For most people using timezones regulalry we will remember the most used zone abbreviations e.g. AEDT instead of australia/sydney or CST instead of america/los_angeles

On arch, I am able to provide up to two timezones, any further timezone is ignored.

❯ TZ_LIST="Europe/Berlin;America/Santiago" tz

  What time is it?

  🕛 (CEST) Local 12:07PM, Sat 15
   0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18  19  20  21  22

  🕕 (-04) America/Santiago 6:07AM, Sat 15
  18  19  20  21  22  23   0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16


 
❯ TZ_LIST="Europe/Berlin;Asia/Bangkok;America/Santiago" tz

  What time is it?

  🕛 (CEST) Local 12:08PM, Sat 15
   0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18  19  20  21  22

  🕛 (CEST) Europe/Berlin 12:08PM, Sat 15
   0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18  19  20  21  22

The current "configuration story" simply loads a list of timezones from the environment variable TZ_LIST: this is just fine for me. The same could be said of the colors: they're just fine for my dark terminal... but probably not for everyone.

If I get enough complaints, maybe I'll consider making the colors a configuratble option, loaded from the user's config. directory. Then the TZ_LIST env var could either disappear or enhance a file configuration variable. 🤔

At midnight, we should have an indication of the current date for each zone, as it is often changing right at this time.

1st off, great tool. Love it!

Now, I installed this tool via Homebrew on my MBP running macOS 10.14.6 Mojave. It works great except for the -q not working. I see that -q was only added to the repos main branch 15 hours ago so maybe it didn't make it into the release used on Homebrew. Just checked and Homebrew is currently using v0.4 and checking the v0.4 tag I see flag package using in main is not present. OK, no prob. Just a note for others who are confused then. Will the -q option be present in v0.5 then?

It would be cool to have an optional argument for a date in the future or past for scheduling events that are not today.

Usage could be something like this:

tz -d $(date -d '+6 month' +%Y-%m-%d)

The UI must allow one to add arbitrary time zones from the tz db.

• key bindings to navigate between the configured time zones (arrows, j, k, ...),
• delete, or backspace, or d should show a confirmation dialog to remove the zone,
• + to show the "add a time zone" dialog where the UI helps auto-complete from the tzdb list.

Notes:

Since go 1.15, there is a time/tzdata package that one can embed to work around cases where the info is not available on the host (this adds 800kb to the binary 🐘).

enhancement

This may or may not be worthwhile for you. I tend to think of the people I'm working with in terms of the city/country that they work in. Since the standard TZ database is small by design, it doesn't really allow one to be specific. For instance, America/Tampa Bay isn't a thing, and so you would choose America/New York or America/Detroit to get to the Eastern Time zone. Off the top of my head, something like:

TZ_LIST=America/Detroit;Tampa Bay,America/Chicago;Minneapolis

Would allow one to display Tampa Bay and Minneapolis for those two time zones.

Just a thought, I love the simplicity of the interface, and using TZ_LIST seems just fine, I didn't see, is there a way to get tz to list out the TZ names for a particular UTC offset?

Neat time tool! A hopefully helpful bug report: When launching tz, it will correctly note a date difference (or lack thereof) between different time zones, but when you use arrow keys to move to other times, it will still maintain the date difference established on launch for all other times, even when it should change. See video, which compares US/Central to US/Eastern time zones. Comparing with US/Pacific shows correctly that there is not currently a date difference, but then continues to claim there is never a date difference at any hour.

The biggest problem I had with getting started with TZ was populating TZ_LIST. The screenshot showed entries like "-07" and "GMT" but the TZ_LIST only understands the full/city_name style. So it'd be helpful if tz had a flag to dump the list, so I could at least grep for relevant entries. Ideally there'd be a UI where I can search and add timezones that tz will remember (~/.config/tz) for next launch.

thanks for the tool. i would find it pleasant to have times displayed in 24-hour format, rather than "AM"/"PM".

I love the program, but it cannot tell me time for example in Dallas, which would be very handy. It would take a map of large cities to timezones. I can contribute this part, if you take PRs.

I noticed that a month ago a "v0.6.2" tag appeared in this repo: https://github.com/oz/tz/tags (which currently matches main -- e23d811)

... but 0.6.1 is still the most recent "release" https://github.com/oz/tz/releases

Is this intentional? Is that tag going to become a release later, or is last year's 0.6.1 still considered "current"?

I ask because right now homebrew is confused, because it's scanning the version-number-looking git tags in the repo:

$  brew livecheck --verbose tz
tz (guessed): 0.6.1 ==> 0.6.2

If 0.6.1 is really the correct "latest release" I can tweak the homebrew livecheck rules for that formula to only consider the github release page and ignore tags. But I don't want to do that if 0.6.2 is merely an accidentally-forgotten release

Thanks for the great software! I think if you were to have a brew install, adoption of the product would be much higher.

The time does update, but the 24-hour clock on after the time zone does not for shift hours. For example, if you do tz and then look an hour later, the wrong hour is still highlighted.

I've recently discovered a nice Github workflow, that automagically creates binaries for (almost) all supported Go binary formats. Once a new Github release has been drafted, the action will build binaries (including a checksum file) for Linux, Windows, MacOS and *BSD and append it to the release page. This would help people without a go build environment to easily get hands on a tz-binary.

I've added the workflow to a project of mine, and it works like a charme. You can see an example here:
https://github.com/wneessen/apg.go/releases/tag/v0.2.9

The action can be found on Github Marketplace: https://github.com/marketplace/actions/go-release-binaries

Since Github workflows (to my knowledge) cannot be PR'ed, I link to the workflow files I am currently using, which have been proven to work w/o issues:
*BSD: https://github.com/wneessen/apg.go/blob/main/.github/workflows/release-bsd.yml
MacOS: https://github.com/wneessen/apg.go/blob/main/.github/workflows/release-darwin.yml
Linux: https://github.com/wneessen/apg.go/blob/main/.github/workflows/release-linux.yml
Windows: https://github.com/wneessen/apg.go/blob/main/.github/workflows/release-windows.yml

Since -q is coming to a future release near you can we also add -v and/or -version/--version so we can check what version is installed without having to dig into the package manager, please? I'd ask for -h and -help/--help but you get that for free with the flag package. 👼

I want to be able to use this for choosing appropriate hours of the day between cities.

The site I use most for this is timeanddate.com

E.g.
https://www.timeanddate.com/worldclock/meetingtime.html?iso=20221023&p1=446&p2=4

In some cases for the current day, there isn't sufficient overlap in working hours to schedule a meeting time, so I want to advance to the next 24 hours of overlap.

When moving the cursor to the right, it currently just winds back around to the beginning of the current 24 hour window, I propose that it now advances and redraws or advances the window forward in time.

When working with several timezones on a daily basis, it can be confusing to remember which timezone corresponds to which person (or persons, in my case) you want to find a suitable time to meet with. It'd be great if we could include names which match timezones. Would be really handy if this would be configurable.

This isn't really an intended use case, but I was curious about what would happen when I ran tz | less. It breaks, unsurprisingly. 😆

tz captures the keyboard, but less is still confused by that. So I can't quit less with 'q'. I think tz should behave as if -q was passed when stdout is not a terminal.

When first coming to this repository I found

particulary appealing since I expected ´tz´ without further arguments to display

A) a list of all timezones
B) timezones at night having a dark background / timezones currently in daytime having a light background

I think both would make for useful features. Could you think of implementing this?

When running ´tz´ I will see my timezone compared to only UTC with a dark background currently.

I understand this app is interactive as in it lets you change the time and show/hide the date, but it would be nice to add an option (perhaps -q?) to just show the output and terminate.

Maybe bind PageUp/PageDown to skip 24 hours ahead/back.

Dunno if the amount moved should be configurable, that's getting close to a whole scheduling thing rather than a quick tool.

Go allows UTC offsets up to a second. Let's aim for that.

$  tz -v       
tz 0.6.1

Ideally this would be automated in some way -- right now the compiled-in version string is hardcoded in main.go: https://github.com/oz/tz/blob/main/main.go#L31