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.
Now my example is not about sunrise / sunset or daytime / nighttime as it were, but if you want to use approximate values for those you can do that, just keep it numeric in a formula, both inputs and results.
Note the Format used on the [MeasureStamp] measure, which makes this measure to return a decimal number.
And related to the initial code (beside what jsmorley said about the numerical values), the mathematical formula used into the Formula option of the [Cycle] measure, is unfinished. Even if it would work with the time stamps, the last section of the formula doesn't have an "after : part": ([MeasureStamp] < 18:59 ? "2"). If the value returned by the [MeasureStamp] measure is below 18:59, the formula would return 2, but what should have to be returned otherwise? The last : 1 (or whatever) section is missing.
One needs to be cautious about Using %#H.%#M as in this example, as it is treating the minute as a percentage of the hour, which it is not. It should be ok with the conditional formula as written, since it can never be 13:72 and you are being explicit, but would give you trouble in other cases. The 59 in 13:59 is not 59% of an hour, it is 98.333333333% of an hour.
P.S. Formulas do not need to use [SectionVariables] and DynamicVariables=1 to access the numeric value of a measure. In this case:
jsmorley wrote:One needs to be cautious about Using %#H.%#M as in this example, as it is treating the minute as a percentage of the hour, which it is not. It should be ok with the conditional formula as written, since it can never be 13:72, but would give you trouble in other cases. The 59 in 13:59 is not 59% of an hour.
Yep, it's not indeed, however the comparation I posted can be used: the ( [MeasureStamp] < 5.59 ) condition compares the current time (returned by the [MeasureStamp] measure) with the 5.59 numerical value. When the current time is up to 5.58 (5:58), the condition is met, however when the time reaches 5.59 (or above), the condition isn't met any more. Works perfectly.
jsmorley wrote:P.S. Formulas do not need to use [SectionVariables] and DynamicVariables=1 to access the numeric value of a measure.
Sorry, but in this case this isn't true. My last posted formula of the [Cycle] measure doesn't work without a DynamicVariables=1 option. I suppose the value returned by Time measures are strings (even if they have a numerical format, like this time) and this requires the option.
Time measures are a peculiar beast. %#H:%#M will return a string value of say "13:59", and since that is NOT a valid number, will return a numeric value that is truncated to the point that the number is valid, or in this case 13. On the other hand, %#H.%#M will return a string value of "13.59", and since that IS a valid number, will return a numeric value of 13.59. If there is NO Format option at all, the measure will return %H:%M:%S as the string value and a Windows timetamp as the number value.
You do not have the required permissions to view the files attached to this post.