It is currently July 13th, 2024, 5:04 pm

Default value of the TimeZone option

Get help with creating, editing & fixing problems with skins
User avatar
FreeRaider
Posts: 826
Joined: November 20th, 2012, 11:58 pm

Re: Default value of the TimeZone option

Post by FreeRaider »

balala wrote: September 4th, 2020, 5:44 pm Hi everybody,

Now it's my turn again to ask something. I have the following extremely simple Time measure:

Code: Select all

[MeasureTime]
Measure=Time
Format=%H:%M
If I add a TimeZone=0 option, I get the current UTC time. This does work.
If I add any valid numeric value to the TimeZone option (eg TimeZone=2 or TimeZone=-5) I get the appropriate time. With TimeZone=local I get the local time. All this are workign as well.
But if I add any (let's say) invalid string (for instance TimeZone=locale or TimeZone=Whatever), I get the time as for TimeZone=0, not my current local time. This seems a little bit intricating, because as far as I know if an invalid value has been used, the measure should use the default value, which in this case should be TimeZone=local.
Where is the mistake?

Thanks in advance.

Hi balala. I think that in the source code of the TIME measure there is no provision for the insertion of a wrong option. Or for any value other than "local" option 0 is indicated as the default.
User avatar
balala
Rainmeter Sage
Posts: 16389
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Default value of the TimeZone option

Post by balala »

Mor3bane wrote: September 5th, 2020, 7:38 am I may have the logic wrong, but the local parameter is indeed the local time the computer uses, whilst 0 is the equivalent to the UTC timezone, as is whatever locations are at -4, and +9. Being numeric as the 0 to + or - 12 range are.
Let's restart, because I have the feeling you didn't understand what I meant.
If for the TimeZone I use a non-valid string (for instance TimeZone=locale instead of TimeZone=local), Rainmeter should use the default value of this option, which in this case, according to the manual, is TimeZone=local. But with TimeZone=locale, the measure works same way as with TimeZone=0. If I set no TimeZone, the measure indeed uses TimeZone=local, returning the current local time. but it doesn't, if a non-valid TimeZone is set. Why?
This was my (still unanswered) question.
User avatar
balala
Rainmeter Sage
Posts: 16389
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Default value of the TimeZone option

Post by balala »

FreeRaider wrote: September 5th, 2020, 9:36 am I think that in the source code of the TIME measure there is no provision for the insertion of a wrong option. Or for any value other than "local" option 0 is indicated as the default.
As usually if a non-valid value is used, Rainmeter should use the default value of the option. But in this case it doesn't, using TimeZone=0, instead of the default TimeZone=local.
User avatar
Mor3bane
Posts: 943
Joined: May 7th, 2016, 7:32 am

Re: Default value of the TimeZone option

Post by Mor3bane »

AH, I got it.

By terms of the manual the default should in any case, whether an incorrect value is set or none, to the local setting.

But it doesn't.

Wouldn't this go to the list of bugs in the developers section?
My DevArt Gallery

There are many ways to be different - there is only one way to be yourself - be amazing at it

The law of averages says what it means; even if you get everything right, you will get something wrong. Therefore; self managing error trapping initiates another set of averages - amongst the errors, some of them will not be errors, instead those instances will appear to be "luck". One cannot complain of the 'appearance' of 'infinite regress of causation', even if it does not have a predictable pattern, only that it requires luck to achieve.
User avatar
balala
Rainmeter Sage
Posts: 16389
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Default value of the TimeZone option

Post by balala »

Mor3bane wrote: September 5th, 2020, 11:46 am Wouldn't this go to the list of bugs in the developers section?
I'm not sure this should be terated as a bug. It's not a bug in my opinion. I'd rather treat it as a mistake in the emanual.
But let's see what the devs say.
User avatar
jsmorley
Developer
Posts: 22646
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Default value of the TimeZone option

Post by jsmorley »

balala wrote: September 5th, 2020, 11:59 am I'm not sure this should be terated as a bug. It's not a bug in my opinion. I'd rather treat it as a mistake in the emanual.
But let's see what the devs say.
I would consider this a bug I think, as I think the way it is described in the manual makes the most sense. In all other cases where there is an "error" in an option value, Rainmeter treats it as if the option doesn't exist, and the default is used, which in this case would clearly be the local time. Let us look into it.

CyberTheWorm has created a very small but real backwards compatibility issue however, as he, and who knows if others, are taking advantage of the "bug" to get behavior they want, and "fixing" this will break his skin.
User avatar
balala
Rainmeter Sage
Posts: 16389
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Default value of the TimeZone option

Post by balala »

jsmorley wrote: September 5th, 2020, 12:34 pm I would consider this a bug I think, as I think the way it is described in the manual makes the most sense. In all other cases where there is an "error" in an option value, Rainmeter treats it as if the option doesn't exist, and the default is used, which in this case would clearly be the local time. Let us look into it.
Yep, this was my guess as well. That's why I started the topic.
jsmorley wrote: September 5th, 2020, 12:34 pm CyberTheWorm has created a very small but real backwards compatibility issue however, as he, and who knows if others, are taking advantage of the "bug" to get behavior they want, and "fixing" this will break his skin.
Even if this is a bug, I think you can leave it as it is. But obviously it's up to the devs, howvere I'm not sure it does worth to modify anything in this direction. My opinion...
User avatar
Brian
Developer
Posts: 2705
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: Default value of the TimeZone option

Post by Brian »

This isn't really a bug, but just how the parsing of options works. It doesn't come up too often since most options are either text based or number based, but rarely both.

In this case, before we attempt to parse a possible formula, we explicitly check for the string "local". If that is not found, we run the option through our math parser for possible formulas. When the math parser finds a non-math related character, it sees it as an invalid formula and returns 0.

All options in Rainmeter work this way, but it isn't really noticeable since most options accept either text or numbers, but rarely both (and numeric options usually default to 0). The "default" value for any option is ONLY used if that option is NOT present in the .ini file. The default value isn't used for INVALID input (at least for most cases, there may be an outlier that accounts for invalid input).

Here is a simple test skin that demonstrates this:

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1

[Variables]
Format=%3!i! hours, %2!i! minutes %1!i! seconds

[MeasureUptime1]
Measure=Uptime
Format=#Format#
AddDaysToHours=1

[MeasureUptime2]
Measure=Uptime
Format=#Format#
AddDaysToHours=oops!

[MeterUptime]
Meter=String
MeasureName=MeasureUptime1
MeasureName2=MeasureUptime2
FontSize=12
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
Text="Uptime:#CRLF#%1#CRLF#%2"
As you can see, AddDaysToHours=oops! is obviously wrong, but according to the docs, that value should default to 1, but it does not. Instead, the invalid input is set to 0.
https://docs.rainmeter.net/manual/measures/uptime/#AddDaysToHours

Here is what I get:
Example.png
-Brian
You do not have the required permissions to view the files attached to this post.
User avatar
balala
Rainmeter Sage
Posts: 16389
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Default value of the TimeZone option

Post by balala »

Brian wrote: September 6th, 2020, 5:40 am This isn't really a bug,
Yes, this was my guess as well.
Brian wrote: September 6th, 2020, 5:40 am In this case, before we attempt to parse a possible formula, we explicitly check for the string "local". If that is not found, we run the option through our math parser for possible formulas. When the math parser finds a non-math related character, it sees it as an invalid formula and returns 0.

All options in Rainmeter work this way, but it isn't really noticeable since most options accept either text or numbers, but rarely both (and numeric options usually default to 0). The "default" value for any option is ONLY used if that option is NOT present in the .ini file. The default value isn't used for INVALID input (at least for most cases, there may be an outlier that accounts for invalid input).

Here is a simple test skin that demonstrates this:
Yep, makes perfectly sense. Good to be known. Thanks for the explanation.
User avatar
Yincognito
Rainmeter Sage
Posts: 7720
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Default value of the TimeZone option

Post by Yincognito »

jsmorley wrote: September 5th, 2020, 12:34 pmI would consider this a bug I think...
balala wrote: September 5th, 2020, 3:37 pmYep, this was my guess as well. That's why I started the topic.
...yet...
Brian wrote: September 6th, 2020, 5:40 amThis isn't really a bug, but just how the parsing of options works.
balala wrote: September 6th, 2020, 11:39 amYes, this was my guess as well.
So...which exactly was your guess, after all? :???: A bug, not a bug, a bug, not a bug, a bug.......not a bug....well, my head is already spinning. :lol:
Just joking, of course, but it was nice to see this back and forth between guesses - I guess that's why a guess is a guess ... if you didn't guessed it already. See what I did there? :sly:

Regarding the UNBUG of this BUG, I don't think it's surprising. The manual states that "if not specified, or set to local, local time for the computer is used", but this isn't either of them, it's just setting it to an invalid value. The result of an invalid value option make sense to be defaulted to 0, IMHO. :confused:
Oh wait, don't tell me: "this was your guess as well". :???: Sorry about this, balala, but just couldn't help it - I hope you don't mind. ;-)

P.S. I know what you meant though. It's just that I liked these apparently contradictory statements. They happen once in a while, just like paradoxes.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth