I know that using the Timeline allows you to hide the “Hour Hand” during specific hours. However, when I set the “Hour Hand” to a designated timezone (such as Eastern Time Zone).
The Timeline is “Sync with Device”. Although I can adjust the specified timezone and the current timezone in the Timeline, the problem arises if the designated timezone observes daylight saving time. In this case, the same method cannot be used to hide the “Hour Hand” in the Timeline, as it would result in abnormal displays during daylight saving time.
Could you please advise if there are other methods to hide the “Hour Hand” based on the specified timezone during specific hours?
I think the problem is the [TMZN_OFS] returning text string with plus or minus sign, which is then not calculated as number.
I would rather try to focus on UTC timestamp, which is independent from local time. (((([UTC_TS]/1000/60/60)%24)+9)%24>=12?0:100)
This shows promise: (1+(round([TMZN_OFS]))).
Obviously the 1+ isn’t wanted; I just used it to verify that the zone was being treated as a number.
This is probably too risky anyway. Not all time zones are integers; I doubt that the format for non-integer time zones is like +9.5; it’s probably +9:30.
Have you considered TMZN_OFS_WITH_DST? Beware that places with the same time zone won’t always have the same daylight saving arrangements, but maybe TMZN_OFS_WITH_DST addresses that.
Thank you for your suggestion. I will try using TMZN_OFS_WITH_DST to convert the timezone string to timezone offset. If I manage to do it, I will share it here.
I still worry that this will break for users in places with non-integer time zones, so it probably shouldn’t be published in the Play Store.
If WFS implemented more of WFF, we’d have access to a string slicing function that would allow dissection of the time zone string so that any minute component could be handled.
If I understand it right, goal was to display something according to fixed predefined timezone. I am not sure whether all timezones change summer time at same date (or at all), but I doubt it.
So
the local DST property does not automatically correspond with the inspected timezone DST.
TMZN_OFS_WITH_DST will also return text that can not be calculated with, same like did the one without DST.
With UTC timestamp you can calculate even for the zones with hour fractions.