Kotofanchik wrote: ↑June 28th, 2024, 8:36 pmOh, no, it doesn’t always work, not for all places. We still have to rack our brains.
Technically, it will work everywhere you use it, if the "Settings.inc" parameter is the correct path and enclosed in quotes, and "[mFullDate]" has a value and is also enclosed in quotes. If by anychance you have quotes inside the [mFullDate] value, you'd have to increase the number of quote pairs enclosing the said value, like ""[mFullDate]"" and such. Also, careful at errors in your logic, since, as I said before:
Yincognito wrote: ↑June 27th, 2024, 11:57 pmI'm afraid that the correct way is in the FinishAction of [mTotal], like I explained in my example. It's merely a coincidence that putting those bangs in the IfTrueAction seems to work, because everything after [!CommandMeasure mTotal Update] will happen before it (instead of right after it), since retrieving data from the web resource is, once again, not immediate.
Kotofanchik wrote: ↑June 29th, 2024, 9:28 am
Is it possible to get the full number of seconds from a full date and time using a timestamp? I can’t figure out a simpler way to compare full dates?
Of course, just use the :Timestamp parameter on an equivalent Time (not String, not WebParser!) measure and compare stuff like that, e.g. [Time1:Timestamp]<[Time2:Timestamp] in either an IfCondition, a Calc measure, or a numeric conditional: https://docs.rainmeter.net/manual/variables/section-variables/#Timestamp
Kotofanchik wrote: ↑June 29th, 2024, 11:53 am
I need to compare two times obtained from regexp, will this not work?
It will work, but you'll need to pass those times to actual / equivalent Time measures that you create with the Timestamp and TimeStampFormat options. Then in the comparison, use the newly created Time measures with the :Timestamp parameter. It's all in the manual, you know...
The skin is the one in this thread. I decided to compare the times on the site in order to find the hourly forecast time as close as possible to the site validation time.. Since the site works very differently in different cities, I could not expand the previous option for all cases, despite the correct logic for a large number of comparisons unstable work began. I tried to do what I read. Here's a piece. All together does not want to work at all. I don’t understand the recording format, why would there be a time stamp after the time stamp? The skin is wildly buggy. I've tried all the comparison signs, but I don't think there's any response.
Kotofanchik wrote: ↑June 29th, 2024, 2:36 pm
The skin is the one in this thread. I decided to compare the times on the site in order to find the hourly forecast time as close as possible to the site validation time.. Since the site works very differently in different cities, I could not expand the previous option for all cases, despite the correct logic for a large number of comparisons unstable work began. I tried to do what I read. Here's a piece. All together does not want to work at all. I don’t understand the recording format, why would there be a time stamp after the time stamp? The skin is wildly buggy. I've tried all the comparison signs, but I don't think there's any response.
[McalcTimeCN]
Measure=calc
Formula=[H16:Timestamp] <= [mfullDateTime:Timestamp] ? 16 : ...and so on, you get the idea...
DynamicVariables=1
Of course, this measure and the other Time measures involved should normally be updated from the FinishAction of [mTotal] (just like in the previous case), in order to perform the comparisons and have a meaningful value with the data retrieved from the site and after retrieving it. Might worth adding all of them to a group and update that group instead, so you don't have to write a line as long as the Milky Way made up of update bangs of every individual measure.
EDIT: By the way, your original code part is actually comparing the plain numeric value of those measures, which in all cases is 2024, as you can see in the log from your screenshot. It wasn't comparing the timestamps, i.e. the number of seconds since Jan 1, 1601.
