Rainmeter Capabilities / World Clock / Single Clock

[peejaygee]

Hey All,

my search words have not helped me in this one, I've tried the forums and I've tried google and putting in 'world clock Rainmeter changing skin' did not help ,as you can imagine, so I'm turning here.

Is Rainmeter capable of having, one skin, one clock, but the clock cycles through timezones?

I'd like to have one clock on my desktop, that cycles through a few preset timezone?

Can it be done through Rainmeter, or should I be looking for alternative solution?

Regards
Paul.

[jsmorley]

Not easily. While you can simply define some timezones as plus or minus some number of hours from your PC's local time, it gets tricky dealing with Daylight Saving time in the locations that observe it. The date that the changes take place varies from country to country (sometimes even city to city) and varies from year to year.

What you really have to do is use WebParser to look up the timezone and DST settings for a given location, from some site that can provide this data in a way you can get at it to parse, without needing some kind of "account" or other login to the site.

You might look at this skin:

https://www.deviantart.com/eclectic-tech/art/Win10-World-Time-780897157

I think eclectic-tech probably uses a method that works.

[Yincognito]

Jsmorley is correct, it is complicated to do it in a direct way, but taking the time from internet sources and putting the clocks in one or several skins on your desktop is quite easy. If you want more options just google "rainmeter clocks timezones" for images, you'll get a few this way.

[jsmorley]

Getting your multiple locations to "toggle" in a single skin is not the hard part. That's pretty easy, once you have the information you need for each location. Getting that information, and keeping it correct and current over time, is the tricky bit.

The world would be a much simpler place if it wasn't for Daylight Saving time.

The real conundrum with this, if you want it to work "correctly", is that DST time changes happen on some particular date, at some particular time, but that date and time is for the timezone you are working with, not your local PC time. Many DST changes happen at 2am on two dates during the course of a year, but it's 2am THERE, not 2am HERE. So in a sense you first have to know the correct current date and time for a location, before you can have the skin use THAT date and time to determine if it the change to DST needs to be triggered.

[Yincognito]

Getting your multiple locations to "toggle" in a single skin is not the hard part. That's pretty easy, once you have the information you need for each location. Getting that information, and keeping it correct and current over time, is the tricky bit.

The world would be a much simpler place if it wasn't for Daylight Saving time.

The real conundrum with this, if you want it to work "correctly", is that DST time changes happen on some particular date, at some particular time, but that date and time is for the timezone you are working with, not your local PC time. Many DST changes happen at 2am on two dates during the course of a year, but it's 2am THERE, not 2am HERE. So in a sense you first have to know the correct current date and time for a location, before you can have the skin use THAT date and time to determine if it the change to DST needs to be triggered.

But doesn't the WebParser internet source handle the DST change, assuming you interrogate a reliable and comprehensive source? You just need to toggle/change the location you use to interrogate the site in order to get the time and date in that location - at least that's how I view the whole thing. It's like getting sunrise/sunset or moonrise/moonset times for different locations with WebParser, instead of computing the whole thing yourself...

[jsmorley]

But doesn't the WebParser internet source handle the DST change, assuming you interrogate a reliable and comprehensive source? You just need to toggle/change the location you use to interrogate the site in order to get the time and date in that location - at least that's how I view the whole thing. It's like getting sunrise/sunset or moonrise/moonset times for different locations with WebParser, instead of computing the whole thing yourself...

So you are going to hit some site with WebParser once a second to drive your clock? I don't think so Tim...

[jsmorley]

In my view, anything that will be "correct" in the strictest terms, must do this for each location:

1) Have some kind of ability to "setup" the location initially. That can be a simple .inc file you edit with the settings, or a more complicated functionality that uses InputText and searches the site for a location and captures and saves the information.

This information must be obtained, or a a minimum kept current, via WebParser. It should be done each time a DST change takes place for the location, so you get a new date and time for the "next" occurrence of that change.

The information you need for each location is:

a) The standard time offset from GMT in hours and minutes
b) The current state of DST for that location.
c) The date and time, local to that location, that the next future DST change takes place.
d) The amount of time involved in DST changes. It's not always an even hour.

2) At regular intervals, perhaps once a minute (which is the lowest increment that can be effected by DST) evaluate the location to see if the local PC time, with the timezone offset from GMT and any current DST impact, has reached the date and time of the next DST change. If so, apply the DST change to the offset from the Local PC time.

3) if DST has changed, update the stored information using WebParser, so you are set for the next future DST change. So basically, twice a year.

4) Have the clock use the local PC time, and apply any timezone offset and any DST offset currently in effect for the remote location.

Anything that tries to directly drive the clock based on WebParser can ONLY be as accurate as the number of seconds/minutes/hours/days between each trip out to the site with WebParser. That can only be either pretty "approximate" concerning DST changes for a location, or a gigantic CPU and bandwidth suck.

A "world clock" is not trivial, if you have any interest in it being accurate.

[Yincognito]

So you are going to hit some site with WebParser once a second to drive your clock? I don't think so Tim...

Every second? Why would I do that? It's not like I'm staring at the clock 24/7. If the clock displays HH:MM, an update every minute is probably enough, and that could be a reasonable query interval for a specialized site. Am I right...Tim?

Just googling for info I found this - this doesn't work for me as I need a valid API key, but just for reference, something like this I had in mind when writing my previous reply (you know, json formatted, free service, etc, etc). It doesn't seem too complicated, assuming you have, like I said, a reliable and comprehensive source to interrogate. But then, what do I know? You are definitely better in Rainmeter intricacies than me, so if you say it's complicated or complex, you are probably correct.

[jsmorley]

Well, if you want to hit some web site in Russia once a minute to get / validate a value that changes twice a year, that's one approach. I wouldn't myself.

But then, I would not attempt a world clock. It would be unsatisfying if it was not really correct, and way more trouble than it is worth if it was.

"Hey Google, what time is it in Paris France?"

Screenshot_2019-01-16-11-58-15.png

[eclectic-tech]

I have found Yandex Time to be the most reliable source for my world time skins.
It avoids having to do any calculations to correct time zones and daylight savings.

The site can return the time, the current weather icon, if it is day/night at that location, & more.

BTW, I update my webparser at the default rate (every 10 minutes); if users can't abide a 10 minute lapse, then they are too picky for me!

Besides the Win10 World Time mentioned by JSMorley, I have used this data in several other skins with good results; illustra WorldTime, Dynamic Suite WorldTime (Horizontal/Vertical).

Dynamic (Horizontal)

Dynamic_WorldTime.png

Ilustra World Time

illustra_WorldTime.png

Feel free to use any of those as a basis for your data, then display it as you wish. (Or just use one of them! )