Hello,
I am looking to create a countdown to a day of week and hour of day. example: Target is "Tuesday 01:00 PST" so on "Wednesday at 16:00" the timer will read "6 d 9 hrs" and "Monday at 18:00" 0 d 7 hrs.
Starting writing it out and its displays "1" on Monday, but I quickly found out I was on the wrong track since I couldn't reconcile hours
$(#DF#)=3?(0)$$(#DF#)<3?(3-#DF#)7+3-#DF#)$
[email protected] said:
Hello,
I am looking to create a countdown to a day of week and hour of day. example: Target is "Tuesday 01:00 PST" so on "Wednesday at 16:00" the timer will read "6 d 9 hrs" and "Monday at 18:00" 0 d 7 hrs.
Starting writing it out and its displays "1" on Monday, but I quickly found out I was on the wrong track since I couldn't reconcile hours
$(#DF#)=3?(0)$$(#DF#)<3?(3-#DF#)7+3-#DF#)$
Click to expand...
Click to collapse
Assuming your target day of the week and hour does not change, can't you do something similar for the hours but use #DH# instead of #Df#:
Code:
$#DH#=1?0$$#DH#<1?1$$#DH#>1?(24+1-#DH#)$
The only problem with this is that your timer will only change at the top of the hour (for example, from 18:00 to 18:59 your timer will continue to read "7 hrs"). Don't know if that's what you want.
Also your code for the number of days needs to be adjusted to insure that each condition is both mutually exclusive (as is if #Df#=3 your code is going to give "(0)7") and also takes into account the time:
Code:
$#DF#=3&&#DH#<=1?0$$(#DF#)<3?(3-#DF#)$$#DF#>3&&#DH#>1?(7+3-#DF#)$
[email protected] said:
Hello,
I am looking to create a countdown to a day of week and hour of day. example: Target is "Tuesday 01:00 PST" so on "Wednesday at 16:00" the timer will read "6 d 9 hrs" and "Monday at 18:00" 0 d 7 hrs.
Starting writing it out and its displays "1" on Monday, but I quickly found out I was on the wrong track since I couldn't reconcile hours
$(#DF#)=3?(0)$$(#DF#)<3?(3-#DF#)7+3-#DF#)$
Click to expand...
Click to collapse
jr67 said:
Assuming your target day of the week and hour does not change, can't you do something similar for the hours but use #DH# instead of #Df#:
Code:
$#DH#=1?0$$#DH#<1?1$$#DH#>1?(24+1-#DH#)$
The only problem with this is that your timer will only change at the top of the hour (for example, from 18:00 to 18:59 your timer will continue to read "7 hrs"). Don't know if that's what you want.
Also your code for the number of days needs to be adjusted to insure that each condition is both mutually exclusive (as is if #Df#=3 your code is going to give "(0)7") and also takes into account the time:
Code:
$#DF#=3&&#DH#<=1?0$$(#DF#)<3?(3-#DF#)$$#DF#>3&&#DH#>1?(7+3-#DF#)$
Click to expand...
Click to collapse
First off, thank you for your help.
I combined your thoughts and tweaked it a little so the display reads 6 D / 11 H which is currently the time until next Tuesday at 4:00 PST in, Since I am EST I had to adjust for that. Interestingly you used #DH# which seems to look at Monday as the first day of the week where I used #Df# which uses Sunday.
Code:
$#DF#=2?6$$(#DF#)<2?(2-#DF#)$$#DF#>2&&#DH#>4?(7+2-#DF#)$-D/$#DH#=1?0$$#DH#<1?1$$#DH#>1?(24+4-#DH#)$-H
Related
So I downloaded and installed Kavana's (sp?) 6.1 on my phone formerly known as the Dash. Anyway, the clock shows the correct time. I haven't fiddled to much with it yet, but noticed last night after midnight, that the digital clock at the very top when you're not on the home screen, showed 00:30 instead of 12:30. Not that it's a big deal, but just wondering why that is. All other hours showed as 9, 10, 11 etc on the PM side, but when it got to midnight, it showed 00:21 or whatever the time was. The clock on the home screen showed 12:whatever but whats with it?
because technically 12:30am is 00:30 till 1:00am.
That is how time is told.
every clock i have at home does that, its normal dont worry about it
zeritooverride said:
every clock i have at home does that, its normal dont worry about it
Click to expand...
Click to collapse
u got some crazy ass clocks ha ha im playin.. but they are right.. so dnt really wrry bout
zeritooverride said:
every clock i have at home does that, its normal dont worry about it
Click to expand...
Click to collapse
Really? I've never owned a clock, watch or anything that showed like that unless it was set to 24 hr time. When set to 12 hr time, it should say 12:30 am not 00:30. Only suggestion I have, is go to bed early and you'll never know.
showaco said:
Really? I've never owned a clock, watch or anything that showed like that unless it was set to 24 hr time. When set to 12 hr time, it should say 12:30 am not 00:30. Only suggestion I have, is go to bed early and you'll never know.
Click to expand...
Click to collapse
Or kill ClockOnTop so it doesn't confuse you.
Its not that its a big deal. I use a 24 hour clock at work every day but if its going to show 00:30 for example, then why doesn't 11pm show up as say 23:00? Only the midnight hour does it. 1pm shows 1 and not 13 etc so I was only wondering why the midnight hour is like that. No clocks anywhere are like that at all. Its either a 12 hour format or a 24 hour format period.
well u can change it to 24
Ill look for the setting in the clock settings. Thanks swaney. I wasn't sure if you could change it to a 24 hour format. Hopefully when I change it to 24 the midnight hour won't show up as 12. Lol. Then I'm sure it was a backwards coding error.
Either Way Its Not Gonna Be Twelve Ots Still Gonna Be 0:00 Cuz Its The Begginnin Of A New Day
Yeah. It is 00 either way. Coding error.
Hello everyone, new members, lurkers and good old friends.I am SammyDroidWiz, presenting a possible reason behind why the 1970 bug specifically says 1970, not really a "fix" but a theory on why the bug chose said year.
The Unix Calendar(Unix Time)
Reddit user metaphorm says this in a /r/eli5 thread(comment permalink):
in the Unix operating system the beginning of the calendar (called the Epoch) is 12:00 am (i.e. 00:00 on the 24 hour clock) January 1st, 1970. the number you're seeing there is the count of seconds since the Epoch.
because this calendar is used for computing it is designed to be convenient for computers rather than for humans, therefore all time is represented as an integer value of seconds. months, weeks, days, etc. are all computed by a program for purposes of displaying the date to humans. internally the machine time format is always in seconds.
Click to expand...
Click to collapse
This states that the Unix time starts at 12:00 am(00:00 military time)January 1, 1970. This starting time is also known as the Epoch.
Internally, Unix time is computed in seconds, while months, days and years only being (re?)computed by a program for purposes of human viewing.
Here is the wikipedia page for Unix Time.
A quote from the Wiki page states:
Two layers of encoding make up Unix time. These can usefully be separated. The first layer encodes a point in time as a scalar real number, and the second encodes that number as a sequence of bits or in another form.
As is standard with UTC, this article labels days using the Gregorian calendar, and counts times within each day in hours, minutes, and seconds. Some of the examples also show International Atomic Time (TAI), another time scheme, which uses the same seconds and is displayed in the same format as UTC, but in which every day is exactly 86400 seconds long, gradually losing synchronization with the Earth's rotation at a rate of roughly one second per year.
Click to expand...
Click to collapse
The above quote states that Unix time may no longer be accurate in seconds/day, graduallly losing sync with the Earth's rotation on its axis by 1 second per year. But I assume that this will not affect our usage of Lunix/UNIX systems like Macs, PCs, Android devices, iOS devices and embedded systems/servers.
Information on the Epoch is also on this quote:
Encoding time as a number
Unix time is a single signed integer number which increments every second, without requiring the calculations to determine year, month, day of month, hour and minute required for intelligibility to humans. Modern Unix time is based on UTC, which counts time using SI seconds, and breaks up the span of time into days almost always 86400 seconds long, but due to leap seconds occasionally 86401 seconds this keeps the days synchronized with the rotation of the Earth as per Universal Time
.
The Unix epoch is the time 00:00:00 UTC on 1 January 1970 (or 1970-01-01T00:00:00Z ISO 8601). There is a problem with this definition, in that UTC did not exist in its current form until 1972; this issue is discussed below. For brevity, the remainder of this section uses ISO 8601 date format, in which the Unix epoch is 1970-01-01T00:00:00Z.
The Unix time number is zero at the Unix epoch, and increases by exactly 86400 per day since the epoch. Thus 2004-09-16T00:00:00Z, 12677 days after the epoch, is represented by the Unix time number 12677 × 86400 = 1095292800. This can be extended backwards from the epoch too, using negative numbers; thus 1957-10-04T00:00:00Z, 4472 days before the epoch, is represented by the Unix time number -4472 × 86400 = -386380800.
Within each day, the Unix time number is as calculated in the preceding paragraph at midnight UTC (00:00:00Z), and increases by exactly 1 per second since midnight. Thus 2004-09-16T17:55:43.54Z, 64543.54 s since midnight on the day in the example above, is represented by the Unix time number 1095292800 + 64543.54 = 1095357343.54. On dates before the epoch the number still increases, thus becoming less negative, as time moves forward.
Click to expand...
Click to collapse
Right below where the quote is taken, there is a table showing the "gradual inaccuracy by seconds/year" which is also on the other quote.
Im thinking that a slight malfunction in the app caused it to restart the Epoch.
Bump
___________________
Curious about the 1970 Tapatalk bug? Read here.
kthxbai
kthxbai
kthxbai
Combo breaker!
___________________
Curious about the 1970 Tapatalk bug? Read here.
Kthxbai
Sent from my LT26i using xda premium
Y U GUYS being so bad to the OT??
Ktnxbai!
That's right, I'm the premium potaytoman and i seek the TROOOOOF! Problem?
Hello everyone,
I know the alarm free date #SAD...# is a beta feature at the moment, but I've run into a bug with it that I thought you should know about.
I have a section on a widget where I show the next alarm date and time, but I want to also show bedtime, which would be the alarm minus 8 hours. I know for standard dates, I can do something like #D-480...# if I want to subtract 8 hours. I can even do math within the variable, such as #D-$(8*60)$...# to subtract 8 hours. When I try this same sort of thing with the alarm free date variable, I find that it compounds amount added or subtracted each minute until something causes it to reset.
To make a simple example, if my alarm is set for 3:30 on Monday, and if I want to display the alarm time with 1 minute subtracted from it, I use #SAD-1 P:mm p#, and I should get 3:29am on Monday. It works correctly for the first minute, but as soon as another minute passes, I see that the the adjusted alarm time now shows 3:28am. So every time a minute passes, the adjusted alarm time gets multiplied by the number of minutes passed since I saved the widget. If I subtract 2 minutes at a time, then I see the time drop by 2 minutes as each minute passes. If I do 8 hours, then, well, it gets very strange very quickly.
I have noticed that the adjusted alarm time will reset from time to time, going back to the correct calculation for a minute, but I'm not sure of what causes the reset. Sometimes it will go back to the correct calculation after editing the widget, and sometimes it won't. Other times it will go back to the correct calculation after my screen has been off for a little bit and then I turn the screen back on, but not every time. Also, it looks like it may not add or subtract additional increments while the screen is off. Again, with my example of subtracting 1 minute, if my screen timeout is 2 minutes, then by the time the screen turns off, I'll see 3 minutes subtracted in total. If I turn the screen back on 10 minutes later, it will still show the 3 minutes subtracted. The next minute that the screen is on, it will either reset to 1 minute being subtracted, or it will continue to 4 minutes subtracted.
FYI, I'm on a Samsung Galaxy Note 3, Android version 4.4.2, Sprint, rooted, but I am running on stock ROM and kernel.
I hope that this helps pinpoint where the bug may be. Please let me know if any other information is required.
Thanks,
Jeremy
Same problem here.
I'd like to make a complex test, i.e. several conditions.
More precisely, I'd like to display the remaining time to next event, under certain conditions. Here is a first example :
$0<#C0sRd#?#C0sRd 'day'#$$1<#C0sRd#?s$ $0<#c0srh#?#C0srh 'hour'#$$1<#c0srh#?s$ $0<#c0srm#?#c0srm 'min'#$.
This line displays the time to next event, but does not displays '0 day' or '0 hour'. But, in case the next event is a full day event (beginning at 12AM) I'd like to display the time to the second next event.
Then I add a test to see if next event begins at 0 hour in the morning :
$0<#C0EH#? #C0sRd 'j'# #C0srh 'h'# #c0srm 'min'#$:#C1sRd 'j'# #C1srh 'h'# #c1srm 'min'#$.
But this line displays '0 day' or '0 hour'.
How can I write the command line that takes both advantages, meaning displays the time to the second next event if next event is full day, AND does not diplay '0 day' or '0 hour' ?
Thank you for your help...
You can use #C0D# and use "&&" (logical AND) to combine conditionals. #C0D# should equal "1" if the next event is all day otherwise it should give you "0".
You can try this:
Code:
$#C0D#=0&&#C0SRd#=1?#C0sRd# day $$#C0D#=0&&#C0SRd#>1?#C0SRd# days $$#C0D#=0&&#C0SRh#=1?#C0SRh# hour$$#C0D#=0&&#C0SRh#?#C0SRh# hours $$#C0D#=0&&#C0SRm>0#?#C0SRm# min$$#C0D#=1&&#C1SRd#=1?#C1sRd# day $$#C0D#=1&&#C1SRd#>1?#C1SRd# days $$#C0D#=1&&#C1SRh#=1?#C1SRh# hour$$#C0D#=1&&#C1SRh#?#C1SRh# hours $$#C0D#=1&&#C1SRm>0#?#C1SRm# min$
I haven't tested this so you may need to tinker with it to get it to work properly. I rewrote parts of your code to eliminate useless blank spaces.
It works fine, thanks a lot !
However, there is still one problem to tackle. Sometimes, I have the following case:
- the first event is an all day event, for today
- the second event is already begun
Then I want to know the time remaining until the 3rd event. Actually, what I want is the time until the next event that is not yet begun.
But the values of #C1SRh# and #C1SRm# give the time between the beginning of the second event and the current moment : it should be negative as the second event is already begun, but it's positive so it's not valuable.
Does anyone know a reliable way to obtain the time remaining until the beginning of the next event that is not yet begun ?
Thanks for your help.
I tried this, to simplify the problem:
$((#DD#-#C0SD#)*1440+(#DH#-#C0SH#)*60+(#Dm#-#C0Sm#))<=0?#C0SRd# d #C0SRh# h #C0SRm# min.$$((#DD#-#C0SD#)*1440+(#DH#-#C0SH#)*60+(#Dm#-#C0Sm#))>0&&((#DD#-#C1SD#)*1440+(#DH#-#C1SH#)*60+(#Dm#-#C1Sm#))<=0?#C1SRd# d #C1SRh# h #C1SRm# min.:#C2SRd# d #C2SRh# h #C2SRm# min.$
It calculates the number of minutes since new year of the current moment and compares it with the numer of minutes since new year of the first and the second event. (1440=60*24)
If current number of minutes minus 1st event's is negative, it means that the 1st event is not yet begun: then display the remaining time to 1st event.
If not and if current number of minutes minus 2nd event's is positive, it means the 2nd event is not yet begun: then display the remaining time to 2nd event; else display the remaining time to 3rd event.
This seams good to me, but is always displays the time time 3rd event : "#C2SRd# d #C2SRh# h #C2SRm# min."
Is there anything wrong with my formula?
Actually, it works if I use one ( and not 2...
$(#DD#-#C0SD#)*1440+(#DH#-#C0SH#)*60+(#Dm#-#C0Sm#)<=0?#C0SRd# j #C0SRh# h #C0SRm# min.$$(#DD#-#C0SD#)*1440+(#DH#-#C0SH#)*60+(#Dm#-#C0Sm#)>0&&(#DD#-#C1SD#)*1440+(#DH#-#C1SH#)*60+(#Dm#-#C1Sm#)<=0?#C1SRd# j #C1SRh# h #C1SRm# min.:#C2SRd# j #C2SRh# h #C2SRm# min.$
Hi,
In my calender widget, I use
Code:
$#C0SRd#>0?#C0SRdd#$$#C0SRd#=0&&#C0SRh#>0?#C0SRhh#$$#C0SRd#=0&&#C0SRh#=0&&#C0SRm#>0?#C0SRmm#$
Basically, I want to see time left from my next meeting.
The problem is, in my calander, I have both start time and end time. ( For example, Meeting with John, start-14:00, end-15:00).
The problem is with this code, as soon as start time begins(i.e. at 14:00), zooper possibly takes the end time (i.e. 15:00) as my C0SRmm and starts showing time left with that respect. So, w.r.t. the example above, if it is 13:05 on the meeting day, it will show 55 min. Which is expected.
But then, if the time is 14:00<current time< 15:00 , e,g. 14:25, it will show 35 min, i.e. time left from the end time...which I don't want.
Any help please?
Are you sure that's the behavior? For me, during an event, #C0SRm# counts the number of minutes from the event's starting time. In your example, for an event starting at 14:00, at 14:25 it will show 25 (really 26 as I see in practice).
ewcrider said:
Are you sure that's the behavior? For me, during an event, #C0SRm# counts the number of minutes from the event's starting time. In your example, for an event starting at 14:00, at 14:25 it will show 25 (really 26 as I see in practice).
Click to expand...
Click to collapse
Sorry...you are right...thats exactly what I get......and I don't want it. I just want to know when my meeting is....not how long the meeting is going.
Barud said:
Sorry...you are right...thats exactly what I get......and I don't want it. I just want to know when my meeting is....not how long the meeting is going.
Click to expand...
Click to collapse
Ok, what do you want it to say instead? Or do you want it to say nothing, or say something like "ongoing"?
I also have a countdown to my next event. I solved this problem using two copies of the countdown, one using event 0 and one using event 1. When event 0 is going on, I hide the countdown for 0 (by setting font size to zero using conditionals in the advanced parameters) and show the countdown for event 1. Otherwise, I hide countdown 1 and show countdown 0.
My test if event is occurring: #DyyyyMMddHHmm#>#C0SyyyyMMddHHmm#
If you just want to hide the countdown, you could add this to your existing conditionals.