I see they handle Daylight saving, albeit they flag that entire week as the change from what I can see for the UK which has a change from GMT to BST (which they call UST+1) on the 28th - yet whole week gets labelled that in which it changes.
Personally I'll be glad when we do away with such daylight saving TZ changes.
It doesn't seem to handle DST properly at all. If I set the date to the 27th, it shows London on the 28th being GMT, if I set it to the 28th it shows London on the 27th being BST. Both wrong. It should instead show the 28th as being only a 23 hour day and the 31st October being a 25 hour day.
Look, you and I may have sane ANSI 16 colours, but it’ll be a very significant fraction of people that don’t (and almost no one will customise the next 240 colours). Remember things like that there’s a distressingly high chance that blue is almost invisible against black, and even bright blue’s contrast is commonly much too low—to say nothing of the limited palette range.
But what this program is doing is using termenv’s HasDarkBackground function to decide whether the terminal is light or dark, and is then specifying RGB colours. It’ll try to guess whether to use 16 colours, 256 colours or 24-bit colour and do some kind of mapping down if necessary (which I bet this app makes a total hash of, probably not having chosen the colours carefully). But the way it figures out the terminal’s background colour… ugh. Some terminals will support it, but for many it’ll fail and just assume black. Looks like on unix you could set an environment variable COLORFGBG to override this, https://github.com/muesli/termenv/blob/6bb55115565c27f4cc681..., but if you’re on Windows, tough luck, apparently you’re not allowed to have a light terminal (which you can get in Command Prompt by running `color f0`): https://github.com/muesli/termenv/blob/537e36cb0472a69a3c828....
The simple fact of the matter is that there are no particularly good solutions for handling colour in terminals if you want the colours to cohere and naturally map to real-world colour understanding, which is what something like this would prefer to be able to do. Things are just barely OK if you just want colours with no inherent semantics.
So… yeah, might be nice if they used the 16 colours, but I can readily understand them not doing so, and if they did do so, although it’d make it better for some, it’d make it worse for others. Where does the balance lie? I dunno.
Agree for raw "syntax highlighting" styling output, disagree for styling the output such as here where the gradient represents additional information/context. Especially since it takes the terminal background configuration into consideration when making that choice.
This is very neat! I can use this at work where I talk to people from all over the world on a regular basis. Will it displace https://worldtimebuddy.com/ in my workflow? I don't know, but it'll be fun to find out.
Not being one of the Cool Kids who has a golang environment ready to go, I logged into my trusty CentOS 7 box and installed golang with "yum install go" which went fine. I cloned the rep and attempted to build:
Some googling[1] led me to 'go list -x' to list the modules, which was failing. I suspected failed IPv6 resolution (an issue on this box) so some more googling[2] led me to add this in /etc/gai.conf:
precedence ::ffff:0:0/96 100
This solved the problem with IPv6 hanging up, as IPv4 is now the preference. Neat. Now, it still failed with another error: invalid pseudo-version
This appeared to be due to an older version of git, so I installed a newer version, again after some googling[3]:
I also had to reinstall golang with 'yum install go' and now I am rewarded with a completed 'go build'. Neat! I am looking forward to checking this little program out.
Seconding the recommendation for https://worldtimebuddy.com - it's a really simple thing it does, but it's somehow the only site/tool I've found that clearly displays the timezones in a way that's easy to understand, including the cross-day issues. It helped a lot for me scheduling meetings between both coasts of the US, India, and Australia.
It looks like this tool does a similar kind of display, so definitely worth giving a shot.
As for this command, I already had go installed on MacOS through homebrew (although I rarely use it in any form) - and the build went fine and the command runs as expected.
One thing I like about woldtimebuddy.com is that you can share the link with others so that everyone is clear on scheduling. The one that always gets me is India, as they're an additional half hour ahead.
> I logged into my trusty CentOS 7 box and installed golang with "yum install go"
Ah well there's your problem!
I'm always nervous about installing language toolchains from the standard repositories on CentOS, because they are often very out of date, or intertwined with the rest of the base system in awkward ways (this is more of a gcc concern perhaps). I have no idea what the state of Go on CentOS is, so this could be baseless nervousness in this case.
If there is a software collection for a toolchain, that may be a better bet than whatever is in the main repo. There is one for Go:
I can't work out what's in it, so i have no idea if it would have made life any easier around your networking or Git issues. I can't even tell what version of Go is in it. The fact that there isn't a Go toolset for CentOS 8 hints that it might be quite out of date.
I'm keeping an eye on https://rockylinux.org/ to see how it pans out. It's got AWS as a sponsor and according to their site "Rocky Linux is led by Gregory Kurtzer, founder of the CentOS project." That bodes well. We'll see how it goes.
Is the diagonal white/black separator in the example supposed to indicate something? It appears to suggest something like "night" towards the right, and it lines up with the numbers, but the numbers on either side of it are different, ranging from 10am/11am to 9pm/10pm.
Edit: Oh! Is it just showing how the UI appears in dark mode? Then the diagonal is meaningless and distracting!
I normally use https://www.timeanddate.com/worldclock/meeting.html which has similar functionality but something that works in the command line definitely sounds interesting. I might give it a go (pun intended haha)
Worldtimebuddy is great but if you're looking for something even better, on Mac you cannot beat 'The Clock' app. Exact same functionality as Worldtimebuddy but goes farther and allows renaming those clocks. If Dan is on EST and Jules is on NRT, rename the EST clock to Dan and the NRT clock to Jules and slide back and forth to easily do the timezone math.
If you work for a cloud company and need to schedule cross AZ work this little app will save your life. What is local time in IAD when SYD is doing 10PM maintenance local time? What about NRT? :-)
33 comments
[ 2.8 ms ] story [ 78.8 ms ] threadPersonally I'll be glad when we do away with such daylight saving TZ changes.
Instead of doing this you should use named colours. "Green" in my terminal is definitely the correct green for my terminal theme.
But what this program is doing is using termenv’s HasDarkBackground function to decide whether the terminal is light or dark, and is then specifying RGB colours. It’ll try to guess whether to use 16 colours, 256 colours or 24-bit colour and do some kind of mapping down if necessary (which I bet this app makes a total hash of, probably not having chosen the colours carefully). But the way it figures out the terminal’s background colour… ugh. Some terminals will support it, but for many it’ll fail and just assume black. Looks like on unix you could set an environment variable COLORFGBG to override this, https://github.com/muesli/termenv/blob/6bb55115565c27f4cc681..., but if you’re on Windows, tough luck, apparently you’re not allowed to have a light terminal (which you can get in Command Prompt by running `color f0`): https://github.com/muesli/termenv/blob/537e36cb0472a69a3c828....
The simple fact of the matter is that there are no particularly good solutions for handling colour in terminals if you want the colours to cohere and naturally map to real-world colour understanding, which is what something like this would prefer to be able to do. Things are just barely OK if you just want colours with no inherent semantics.
So… yeah, might be nice if they used the 16 colours, but I can readily understand them not doing so, and if they did do so, although it’d make it better for some, it’d make it worse for others. Where does the balance lie? I dunno.
Not being one of the Cool Kids who has a golang environment ready to go, I logged into my trusty CentOS 7 box and installed golang with "yum install go" which went fine. I cloned the rep and attempted to build:
git clone https://github.com/oz/tz
cd tz
go build
Nothing. Nada. Dead. Not even an error.
Some googling[1] led me to 'go list -x' to list the modules, which was failing. I suspected failed IPv6 resolution (an issue on this box) so some more googling[2] led me to add this in /etc/gai.conf:
precedence ::ffff:0:0/96 100
This solved the problem with IPv6 hanging up, as IPv4 is now the preference. Neat. Now, it still failed with another error: invalid pseudo-version
This appeared to be due to an older version of git, so I installed a newer version, again after some googling[3]:
yum -y erase git
yum -y install https://repo.ius.io/ius-release-el7.rpm
yum -y install git222
I also had to reinstall golang with 'yum install go' and now I am rewarded with a completed 'go build'. Neat! I am looking forward to checking this little program out.
[1] https://github.com/golang/go/issues/16104 [2] https://stackoverflow.com/a/21672312 [3] https://github.com/golang/go/issues/38373#issuecomment-70187...
https://www.youtube.com/watch?v=lKXe3HUG2l4
It looks like this tool does a similar kind of display, so definitely worth giving a shot.
As for this command, I already had go installed on MacOS through homebrew (although I rarely use it in any form) - and the build went fine and the command runs as expected.
Ah well there's your problem!
I'm always nervous about installing language toolchains from the standard repositories on CentOS, because they are often very out of date, or intertwined with the rest of the base system in awkward ways (this is more of a gcc concern perhaps). I have no idea what the state of Go on CentOS is, so this could be baseless nervousness in this case.
If there is a software collection for a toolchain, that may be a better bet than whatever is in the main repo. There is one for Go:
https://www.softwarecollections.org/en/scls/rhscl/go-toolset...
I can't work out what's in it, so i have no idea if it would have made life any easier around your networking or Git issues. I can't even tell what version of Go is in it. The fact that there isn't a Go toolset for CentOS 8 hints that it might be quite out of date.
Comment to dev: Please provide better documentation. Installation steps and configuration are terribly lacking.
That site is a bit too sparse for my liking. I find the following to have a decent landing page:
* https://everytimezone.com
Edit: Oh! Is it just showing how the UI appears in dark mode? Then the diagonal is meaningless and distracting!
Light: https://postimg.cc/BPW3vwJN
Dark: https://postimg.cc/dkZvwKcL
I normally use https://www.timeanddate.com/worldclock/meeting.html which has similar functionality but something that works in the command line definitely sounds interesting. I might give it a go (pun intended haha)
Kinda surprised the readme didn't mention it. Is this not the preferred way to install go CLI tools now with 1.16+ ?
If you work for a cloud company and need to schedule cross AZ work this little app will save your life. What is local time in IAD when SYD is doing 10PM maintenance local time? What about NRT? :-)