Use : instead of. in variable %TIME

[Glen]

is there a way to show 2:00 instead of 2.00 for the variable %TIME?

[Svampsson Svampsson]

Set it to a local variable and run a search replace.

[Pent]

Some more detail:

Variable Set, %time, %TIME
Variable Search Replace, \. , :  (\. is the Search parameter, : is the replace parameter)

Pent

[Glen]

thanks Pent

anyway to cover it to 12 hours format?

[Pent]

Variable Split to get the two parts.

Variables Subtract to take 12 from the first part.

if < 12, add "am" to the result, otherwise add "pm" to the result.

Pent

[Rich D]

> Variable Split to get the two parts.
>
> Variables Subtract to take 12 from the first part.
>
> if < 12, add "am" to the result, otherwise add "pm" to the result.

Or, let tasker do the heavy work for you...   :)

get time (61)
A1: Variable Convert [ Name:%TIMES Function:Seconds to Long Date Time Store Result In:%time ]
A2: Variable Split [ Name:%time Splitter: Delete Base:Off ]
A3: Flash [ Text:%time(5) Long:Off ]

[Pent]

In my defence, you use it more than me :-)

Pent

[Rich D]

> In my defence, you use it more than me :-)

I see the method to your madness... 

Your method = Requires better understanding of tasker actions = More educated tasker users = Less Questions...

I get it....  :)

[Christopher Scott]

Glen,

I think what you are really asking is how do I convert from zulu time (the value contained in the variable %TIME) to standard time (the value 2:00 pm). If not, then I'm sorry for all that I am about to write. However, as I searched high and low for how to convert from zulu to standard time about one month ago, I am going to walk this through, step by step.

Several of the responses addressing your question get you pretty close to the solution to your question, but a few exceptions have to be dealt with. Pent's approach to converting from zulu to standard time is pretty close to how I have handled the Zulu time issue, but beginners will need greater detail. Here goes....

• Variable Split to get the two parts. Let's assume the variable %TIME contains 0.41, which, in standard time, is 12:41 am.
  

Action - Set Variable: set variable %zulu_time to %TIME [Use any name you'd like for the new variable. I just like the name %zulu_time.]
Action - Split Variable: %zulu_time using . (the period keystroke) as the splitter
Action - Set Variable: %raw_hour to %zulu_time(1) [Remember, after splitting the variable %zulu_time, the variable becomes an array with two elements containing 0 and 41. Thus, when you refer to %zulu_time(1), you are actually calling the first element of the array, in this case the value 0.]
Action - Set Variable: %raw_minute to %zulu_time(2) [You'll see why I use the variable names %raw_hour and %raw_minute in the steps below where you will process these variables.]

• Variables Subtract to take 12 from the first part. I'm gonna walk you through this step by step, as you'll need some IF/THEN/ELSE logic to get through converting zulu hours to standard format hours. Basically, you''re going to transform the variable %raw_ hour, which is in zulu, so that the variable represents the hour in traditional time.
  

However, before you deal with that transformation, you must first deal with setting a variable to represent either am or pm depending on the zulu hour time value. So...

Action - Variable Set: set the variable %meridiem to am IF %raw_hour less than (<) 12
Action - Variable Set: set the variable %meridiem to pm IF %raw_hour greater than (>) 11 [Unfortunately, Tasker does not provide a "greater than or equal to" function, so the greater than and less than functions have to be set a bit obtusely. Thus we use the logic >11 to set the variable %meridiem if %raw_hour it is between 12 and 23.]

Now lets handle the hour component of the time....

Action - Variable Subtract: subtract 12 from the variable %raw_hour IF %raw_hour greater than (>) 12 [Note that 12 will only be subtracted from the variable %raw_hour if the variable contains a value between 13 and 23 (1 pm to 11 pm). The variable %raw_hour is unaltered if it is between 12 am to 12 pm.]

Here's the trick with the zulu hours, tho: Remember, the zulu time value we are working with is 0.41. In standard time, the zulu hour 0 is represented as 12 am in standard time. (You've probably heard the phrase "zero hundred hours" in a war movie. This is where that phrase comes from.) You have to catch this exception to the above logic in order for your time conversion to work correctly, which can be done in a single IF/ELSE step. So....

Action - IF: %raw_hour equals 0

Set Variable: %hour to 12

ELSE IF: %raw_hour does not equal 0

Set Variable: %hour to %raw_hour

END IF

Pent's next action is...

• if < 12, add "am" to the result, otherwise add "pm" to the result. We handled this step above as this is a bit out of sequence....

----------

Now you have to handle the minutes piece of the conversion from zulu. While this seems straight forward, there is an exception you must catch: if %zulu_time(2) represents any even hour time value (for example, 10:00 am, 1:00 pm, 6:00 pm, etc.), the element %zulu_time(2) will contain 0. So....

Action - IF: %raw_minute equals 0

Set Variable: %minute to %raw_minute0 [This step just adds an extra zero to the variable %minute if %raw_minute is zero. This allows you to show the correctly formatted  time - 12:00 - rather than the ill formatted time - 12:0.]

ELSE IF: %raw_minute does not equal 0

Set variable: set variable %minute to %raw_minute

END IF

You can now format the correct standard time for presentation in your scenes or for use in your tasks.

Action - Variable Set: %Standard_Time to %hour:%minute %meridiem [This results in %Standard_Time containing 12:41 am based on the original value of %TIME - 0.41. Also, using initial caps when naming the variable %Standard_Time allows any task or scene to access the variable. In other words, the %Standard_Time is public.)

- TIP -

You'll probably want to use the above actions anytime you want a variable containing a standard time value. So let's go crazy; let's get nuts! Let's create a Tasker "object" that performs the activity "Convert Zulu to Standard Time." We'll call the object Zulu Time Converter.

But wait, you say, Tasker doesn't use objects! Wrong, I say. Tasker just doesn't call objects "objects." It calls them "tasks." (I won't get into a lot of CS philosophy or dogma here. Just trust me.)

So create a new task and call it Zulu Time Converter. Populate the task with the actions above. "Save" the task (in other words, exit the task editor UI).

Zulu Time Converter never gets called directly by a profile. It is just a tool your other tasks can use when they need a variable representing a standard-time value. To call the task, use the Action -  Task -> Perform Task. When you call Zulu Time Converter, give it the priority "priority+1." This allows Zulu Time Converter to finish before the parent task calling it moves to the next action, which hopefully needs a variable representing a standard time value.

IMPORTANT: after calling Zulu Time Converter, remember the variable containing the standard time value is contained in %Standard_Time. Right after the action Perform Task, use the Action - Set Variable and set a task-specific variable (%call_time, for example) to the value of %Standard_Time.

Why do this? Well, you may have more than one task calling Zulu Time Converter and every time Zulu Time Converter runs, the value of %Standard_Time changes. So grab the value from %Standard_Time and evermore assume the value of %Standard_Time has changed thereafter. Never use the value of %Standard_Time without calling the task Zulu Time Converter first.

Hope all of this helps you and anyone who wrestles this problem in the future.

[Pent]

Pretty comprehensive, thanks Christopher :-)

Mystified as to why you want to confuse things by calling tasks
'objects'. In a software sense, 'objects' usually consist of code and
data.

Pent

[Rich D]

>
> I think what you are really asking is how do I convert from zulu time (the value contained in the variable %TIME) to standard time (the value 2:00 pm)

Would not the approach i I listed be much simpler?

For clarity if you have a "Zulu"  Time in a variable (IE 0.45) that is not the current time and would like to convert that you can not use the %TIMES variable listed in my first post. To do this you just need to add the date with a space to your zulu time then convert to seconds then convert to 'long date Time'

That is still a much simpler solution then doing all the math.

get time (61)
A1: Variable Set [ Name:%zulu To:0.45 Do Maths:Off Append:Off ]
A2: Variable Set [ Name:%zulu To:%DATE %zulu Do Maths:Off Append:Off ]
A3: Variable Convert [ Name:%zulu Function:Date Time to Seconds Store Result In:%seconds ]
A4: Variable Convert [ Name:%seconds Function:Seconds to Long Date Time Store Result In:%time ]
A5: Flash [ Text:%seconds Long:Off ]
A6: Variable Split [ Name:%time Splitter: Delete Base:Off ]
A7: Flash [ Text:%time(5) Long:Off ]

[Christopher Scott]

Great question, Pent!

Think of a task as having state (data) and behavior (actions/methods). A task's actions equate to behavior that acts on the data the task has or receives from another task when it is called.

I know I risk creating confusion, but I have been experimenting with abstraction, aka creating tasks that do one thing and that can be used over and over again by other tasks. The Convert Zulu Time task is a great example of a task that does just this: it takes the value in a system variable, %TIME, and turns it the value into a more commonly used format. Plus, treating of the task Convert Zulu Time as an "object" has added benefits:

(1) The tasks calling/invoking Convert Zulu Time do not have to "care" about how Convert Zulu Time performs the conversion. They just expect to receive a variable with a value that is formatted as the current standard time.

(2) If you find an error in the logic, flow, and/or control with how you are converting from zulu, you only have to make changes to the task Convert Zulu Time. This makes maintaining your tasks' code much easier. Can you imagine having 6 tasks that need to convert from zulu and  then having to update the code in all 5? Oops - you missed the 6th. This is the story of my life! I am 50 and suffer from an acute case of CRS.

All of this said, it is important to remember, if tasks were objects, they are really an implementation of the singleton design pattern. In Tasker, you can't "new up" a task. (I link to the pattern's definition for those who don't know this pattern and want to know more. Of course, this turns you into a geek like me.)

Again, for the uninitiated, "new up" is short hand for a new object being created based on a class definition. Typically, a new object is created to work with the object calling it, just like one task calls another through Task-> Perform Task. However, Tasker, wisely in my opinion, does not create a new "instance" of the task for you to work with. You simply work directly with the task you call - thus the task is the equivalent of a singleton object: a single task exists and every other task works directly with that single instance of the task.

Now, remember, in my earlier post, I instructed users of the task -- aka singleton object -- to get the variable %Standard_Time and immediately assign the value to a new variable in your task. An example reason for this is, it might be hard to remember how many tasks are running and how many of those tasks use Perform Task -> Convert From Zulu. Every time one of those running tasks using the action Perform Task, the value of %Standard_Time changes. (In an object-oriented language like Java, the variable is probably updated every second whether the method for retrieving the %Standard_Time variable is invoked or not. The variable %TIME does this.) Thus, when I was taught object-oriented programming, I was told, (1) call the method to get the system-wide variable, in this case %Standard_Time,  and then (2) immediately assign the value to an object-specific variable you can work with, maybe a variable called %my_time, but use whatever you want for this variable's name.

The same practice should be used when dealing with the variable %Standard_Time! If you remember this one best practice, the task Convert Zulu Time will work great for anyone using the task Convert Zulu Time.

Pent, you probably know all of this already. I assume you are programming Tasker in Java. However, when I search across the web for how to handle a problem, I notice many users do not know the basics of programming best practices, which would help them immensely, and complain they do not know Java and, thus, can't use the action Code->Java Code. I figure I might as well start answering questions in a manner that helps everyone who searches the web for how to deal with a problem, in this case converting from zulu. I figure, the advanced user will just blow by most of my in-detail explanations and grab what s/he needs.

However, the inexperienced Tasker user has just about no chance of understanding what your original response is telling him/her to do. It's just too abstract, like telling the inexperienced cook, "First, make a bechamel sauce." I cook and know how to do that, as do most people who cook. However, my wife, who doesn't do more than heat up meals in the oven and cook pasta, has no idea (1) what a bechamel sauce is and (2) how to make one. She needs a book called Cooking for the Inexperienced. I guess at some level that is what I am trying to write that book, but for Tasker.

Plus, I'm long winded. ;)

Best,
Christopher

[Christopher Scott]

Rich,

I love your solution. It is light and elegant. If thousands of tasks were running and you needed to think about how lines of code impact processor load, yours is an implementation that I would love even more!

But one thing: it is difficult to understand the code at first blush, and you have to know Tasker pretty well to really "get" how things are working.

In Tasker, I try to comply with the tenants of self-documenting code:

• Make source code easier to read and understand
• Reduce the need for others to consult secondary documentation sources such as on-line forums and tutorials

Okay, I skipped a few,  but you get where I'm going.

When writing about a solution to a question, I want the reader to intuitively understand what each action is doing, and I assume the person asking a question, unless otherwise manifested, is probably less experienced than the person answering the question. You are clearly more experienced, more experienced that I am! I would never have come up with your solution to the question. Unfortunately, my head just doesn't work that way. (I suck at solving most complex puzzles that don't rely on a clear process to solve them, and I have relatively little experience with mathematical algorithms.)

Then we have the classic QA problem: I know what I did/wrote and it is self documenting. Of course it is... to you! You wrote the code. The only real test of self-documenting is if Glen understands what you wrote without having to spend time on the web figuring out what each action does. For what it is worth, I don't understand what each of your actions does, but that is just me. I could understand each action with a little work. I don't mind doing the work. In fact I will. But that means your solution isn't self documenting, at least to me.

Which brings me to my last point. (Thank god, you say!) I came to preach to the software development teams I managed, Write code for the lowest common denominator and if you can't do that, make thorough comments in your code. (This violates at least one tenant of self-documenting code, I know, but it is better than having four developers standing around trying to figure out what you did.) What was the lowest common denominator, because clearly that denominator isn't a constant? It was me. I knew the basic tenants of OO development, had a working knowledge of Java, and had usually created the system architecture, which I tried very hard to make understandable by its very structure. I didn't always succeed.

I once had a partner in the firm I was working for ask me, Why did you try to implement such a complex solution? A lack of clear requirements creates complexity, I answered. He wasn't impressed, but I still stand by my statement.

Best,

Christopher