Default value of the TimeZone option

[FreeRaider]

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.

[balala]

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.

[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.

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.

[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?

[balala]

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.

[jsmorley]

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.

[balala]

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.

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...

[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

[balala]

This isn't really a bug,

Yes, this was my guess as well.

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.

[Yincognito]

I would consider this a bug I think...

Yep, this was my guess as well. That's why I started the topic.

...yet...

This isn't really a bug, but just how the parsing of options works.

Yes, 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.
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?

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.

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.