time is incorrect across all clocks and skins.

[David8192]

this is kind of a stupid answer, no offence.

OBVIOUSLY IF I HAVE INTERNATIONAL CLOCKS IT'S BECAUSE I WORK ACROSS MULTIPLE TIME ZONES.

If I want to organise a meeting with a client in Berlin while I am in Sydney, I want Rainmeter to at least be accurate with the Berlin time.

To note - there is also nothing wrong with my system time - its a FRESH INSTALL of Windows 10. There is a also a native Windows 10 function for adding an extra city clock for international people, and windows get this 100% correct.

Rainmeters problem is daylight saving. Rainmeter only seems to calculate international times by adding or subtracting the timezone offset and does not take into account daylight saving.

So in this regard, Rainmeter is useless for international multi-time clocks.

Is it a stupid answer or you are just lazy? No offense. Just do Daylight saving adjustments in the skins.

[bendy303]

still stupid answer.

You want me to have a spreadsheet of all the daylight savings in the world - and manually adjust them in the clocks when they change for each city?

dumb.

[bendy303]

ok maybe I misunderstood what you meant.

Did you mean manually do the offset for each clock according to daylight savings?


this below is the right answer, someone else on my other thread answered with.

under the [measureTime] heading in each city clock, have:

DaylightSavingTime=0


however, do not do this for the local time, as windows does it automatically.

[David8192]

ok maybe I misunderstood what you meant.

Did you mean manually do the offset for each clock according to daylight savings?


this below is the right answer, someone else on my other thread answered with.

under the [measureTime] heading in each city clock, have:

DaylightSavingTime=0


however, do not do this for the local time, as windows does it automatically.

If DaylightSavingTime is set to 0 and TimeZone is supplied, the current local offset for Daylight Saving Time is not applied to the value.

Note: All locations do not follow the same Daylight Saving Time schedule, if any. If a Time measure is intended to provide the time in a specific location, and that location follows a different schedule from the user's local system, the default value will be wrong on certain dates over the course of the year. In order to provide an accurate time, DaylightSavingTime must be set to 0, and TimeZone must be set in a way that accounts for the current Daylight Saving Time rules for that location.

[balala]

still stupid answer.

Sorry being so stupid. Don't worry, will try not to be anymore.