Daylight Savings Time determination within tasker?

[hippoma...@gmail.com]

Without running any software that make queries over the network, and with Location Services turned off, is there any way within a Tasker task to determine whether Daylight Savings Time is currently in effect for the given device?

The current time is certainly available on the device, but I don't know if there is a way to query whether or not that time represents a Daylight-Savings-Time value.

Thanks in advance for any suggestions.

.

[nanobrain]

Run Shell with the command "date +%Z" gives EDT for me when DST is in effect, EST when not. 

[hippoma...@gmail.com]

On Friday, July 4, 2014 10:57:30 AM UTC-4, nanobrain wrote:

Run Shell with the command "date +%Z" gives EDT for me when DST is in effect, EST when not.

Thank you. I know I can do this. I forgot to mention in my original message that I'm hoping to determine DST status within Tasker without running any external linux commands.

Am I out of luck?

.

[Bob Hansen]

See this:

datetime - Calculating daylight savings time from only date - Stack Overflow

[hippoma...@gmail.com]

On Friday, July 4, 2014 11:06:30 AM UTC-4, Bob Hansen wrote:

See this:

datetime - Calculating daylight savings time from only date - Stack Overflow

Thank you. Yes. I know how to do this in Java, both within Android and under other environments. However, I don't know of a way under Tasker to directly get the return value of the following Java method call: TimeZone.inDayLightSavingsTime(new Date()).

Also, I know I can hard-code the DST algorithm myself within a Tasker task, given the current USA DST conventions. However, I've been looking for a way to simply query some sort of system or Tasker attribute within a Tasker task that tells me whether we are currently running under DST.

I guess this just isn't possible.


.




[nanobrain]

Do a Variable Convert of %TIMES Seconds to Date Time and compare to Variable Convert of %TIMES+244*86400 (daylight savings time in the US lasts between 3/8 at the earliest and 11/7 at the latest = 244 days). If the difference between the first time and the second time is positive DST is in effect, if negative it is not. 

Of course this depends on which country you are in :)

[nanobrain]

On further thought this probably won't work right before switch to DST f the DST duration is less than 244 days. I guess you have to test for several days into the future. And of course if you are in AZ or Hawaii the difference in times will always be 0.   

[Matt R]

What's the problem with doing a run shell action?

Matt

[hippoma...@gmail.com]

On Friday, July 4, 2014 12:29:19 PM UTC-4, Matt R wrote:

What's the problem with doing a run shell action?

Matt

I just want to avoid shelling out every time I do a time conversion from %TIMEMS (I do that frequently in some of my tasks in order to create human-readable timestamps). However, given that I need to invoke such a shell action, I decided to optimize it as follows:

I created the following shell script (see below) which returns the offset in milliseconds between local time and GMT. I created a task which invokes this script and which stores its output in a variable called %GMTOffset. I cause this task to be invoked every day at 3:05AM, and every time I restart my device.

Then, every time I want to format %TIMEMS to a human-readable timestamp, I just subtract %GMTOffset from %TIMEMS before doing that conversion.

Here's the script:

#!/system/xbin/sh

date=/system/xbin/date

fmt='%Y/%m/%d %H:%M:%S'

ts=$(${date} "+${fmt}")

curr=$(${date} -u -D "${fmt}" -d "${ts}" '+%s')
utc=$(${date} -D "${fmt}" -d "${ts}" '+%s')

echo $(( ( utc - curr ) * 1000 ))

exit 0

[Matt R]

Doing variable convert doesn't already do it in the right time zone?

Matt

[hippoma...@gmail.com]

On Friday, July 4, 2014 2:37:28 PM UTC-4, Matt R wrote:

Doing variable convert doesn't already do it in the right time zone?

Matt

%TIMEMS is in units of UTC. I do my own, non-standard timestamp conversions, down to the millisecond. I format it in my own way, doing my own math, and therefore, I need to convert the %TIMEMS value to something that's valid in my own timezone.

.

 

[hippoma...@gmail.com]

PS: The format I want is this:   YYYY-MM-DD HH:MM:SS.XXX where "XXX" are milliseconds, and where the timestamp is shown in local time, not UTC.

I can easily produce this format using a task that starts with %TIMEMS and applies various subtractions, mod operations, etc. It works fine, and it seems to be efficient.

Something like strftime() would be a great addition for Tasker. In its absence, my timestamp-producing task works with no problems.

.

 

[Brandon Horwath]

As a side note, I'm looking to try and do the same... mostly.

I need to determine if daylight savings applies to the target date of an event in the calendar as opposed to the current date, and vice-versa. Ideally, factoring in the specified 'location' of the calendar event as well. Actually if location wasn't factored it would be fairly useless :/

So, I am looking for a variation of date + %z but for a future date, not the current one. I can work out a method of comparison against location later but, really if this syntax could be modified for what I need that make the process way easier.

[hippoma...@gmail.com]

Look at the "-d" and "-D" options to "date". The "-d" option allows you to specify any date. The "-D" option allows you specify the format of the date supplied in the "-d" option.

The command that would work for you under android would be something like this:

/system/xbin/date -D "%Y-%m-%d %H:%M:%S" -d "2022-12-03 07:32:51" "+%z"

This assumes the use of the busybox "date" command in /system/xbin/date. I'm not sure what options are available for the non-busybox /system/bin/date.

.

[Brandon Horwath]

Thanks for the suggestion, just wanted to confirm that's a shell command that requires root?

[hippoma...@gmail.com]

On Friday, July 4, 2014 6:42:10 PM UTC-4, Brandon Horwath wrote:

Thanks for the suggestion, just wanted to confirm that's a shell command that requires root?

I doubt that "date" requires root. Since my phone is rooted, I can't test this. However,"date" doesn't require any special permissions to run, unless it's utilized to set the system date. Since you're using it simply to do date formatting, you should be OK without root.

However, there is one caveat: I have just checked, and the non-busybox version of "date" (/system/bin/date) doesn't support the "-d" and "-D" options. You need to use the busybox version of that command (/system/xbin/date).

I don't know whether you can install busybox without root.

.

[Scott Miller]

You can use the BusyBox binary without root, but it can't create the symlinks, so you need to call it through BusyBox.

Scott

--
You received this message because you are subscribed to the Google Groups "Tasker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tasker+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/tasker.
For more options, visit https://groups.google.com/d/optout.

[hippoma...@gmail.com]

On Friday, July 4, 2014 8:36:52 PM UTC-4, Scott Miller wrote:

You can use the BusyBox binary without root, but it can't create the symlinks, so you need to call it through BusyBox.

Thank you.

So, Brandon, you can simply say "busybox date" instead of "/system/xbin/date", and the example I gave you should work.

.

 

[Brandon Horwath]

Okay, that sounds promising :-)

I will need to play around with it. And install: https://play.google.com/store/apps/details?id=stericson.busybox

The problem I am having, is creating calendar events using tasker that complies with 'starting in x minutes' field for entry. I can calculate the total number of minutes between two given periods, except it's off by an hour either way when daylight savings applies or no-longer applies.

I'm hoping this method will be the most efficient.

Thanks again!

[hippoma...@gmail.com]

Glad to help!

Also, I recommend that you do the calculation of the delta between the two time periods within one shell script which takes the two times as arguments and which returns the interval between them.

This guarantees that the date math is being performed within a single, atomic call (well, atomic from Tasker's point of view).

.