It's not always an even hour.Ģ) 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. The information you need for each location is:Ī) The standard time offset from GMT in hours and minutesī) The current state of DST for that location.Ĭ) The date and time, local to that location, that the next future DST change takes place.ĭ) The amount of time involved in DST changes. 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. This information must be obtained, or a a minimum kept current, via WebParser. 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. In my view, anything that will be "correct" in the strictest terms, must do this for each location:ġ) Have some kind of ability to "setup" the location initially. It's like getting sunrise/sunset or moonrise/moonset times for different locations with WebParser, instead of computing the whole thing yourself. 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.īut 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. Many DST changes happen at 2am on two dates during the course of a year, but it's 2am THERE, not 2am HERE. 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. The world would be a much simpler place if it wasn't for Daylight Saving time. Getting that information, and keeping it correct and current over time, is the tricky bit. That's pretty easy, once you have the information you need for each location. Getting your multiple locations to "toggle" in a single skin is not the hard part. Please forgive me if I've missed something obvious: I'm a real newbie.Jsmorley wrote: ↑ January 16th, 2019, 3:40 pm But a steer in the direction of what features to explore would be greatly appreciated.
Indeed, that's more than half the fun - even having to take into account that Shape Rotate uses degrees, not radians like some other features, and that there's a mixture of pixels and multiples-of-Strokewidth utilized as measurement units. I'm not expecting someone to write all the code for me. After seeing some of the brilliant examples of how the new Shapes can be used, I turned to the Loop measure, but the documentation for that is a little inaccessible for the newcomer, and anyway I couldn't find an analog clock skin that relies on it.Ĭan someone point me to features of Rainmeter that can be used to make an analog clock that will work using vector Shapes for the clockface and hands? Constructing the Shapes themselves isn't the problem: it's how to make the hands turn, given that the Shapes don't seem to be able to be used by Rotator or Roundline. It seems that neither the Rotator nor the Roundline meters are able to use the new Shapes. The new Shape meter is great - congratulations to the developers - but I haven't worked out how to make an analog clock skin using the new Shapes.