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. I don’t think there is any other weather skin that works as well.Jsmorley wrote: ↑ January 16th, 2019, 3:40 pm SilverAzide has been diligent on keeping up and releasing fixes. has repeatedly changed their API interface. I have delayed some updates but the small development team is very good about releasing working products (probably better testing than a well known Redmond WA company). And Rainmeter has been very reliable on Win10. I cannot find any reason to believe that Rainmeter skins would pose a security risk. I’ve written a few of my own (I really like to just glance at the lower right corner of the desktop and see “Win -19041.388”.) It isn’t the easiest product to set up as the OP noted but they surely are nice (and not too hard to build your own simple item).įor your questions: Live tiles only work on Start not the desktop. Most from which set out to replicate the Win7 Gadgets. I have 8 “skins” running on my desktop right now. I’ve used Rainmeter for some years now on Win10.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |