I'm making a project on android studio.
I must convert a number into an hour, minutes and seconds date.
The number is: 0,18865386
The result must be: 04:31:40
I've obtained this date whit excel (used for test calc) just changing the cell format to HOURS but i don't understand how to calculate it.
Any solutions?
1 corresponds to 24 hours.
In hours: 0,18865386 means 24 x 0,18865386 ~= 4,5 hours which corresponds to your 04:31:40.
If you need more precision, e.g. in seconds:
The number of seconds in a day = 24 x 60 x 60 = 86400.
Then 0,18865386 means 86400 x 0,18865386 = 16300 seconds = 04:31:40.
Related
I'm successfully registering a SipProfile with 1 hour expiration. I see the REGISTER message in Wireshark on the SIP server machine, re-sent with authorization.
Brekeke replies immediately with a STATUS: 200 OK, passing back 'Expires:3600'.
Both Xamarin and Android docs tell me that lExpire should be duration in seconds before the registration expires, so it represents an interval. I want to expose received values, so multiply by TimeSpan.TicksPerSecond (to convert to TimeSpan), 3600 would result in 0.01:00:00:
void ISipRegistrationListener.OnRegistrationDone( string lclPrfUri, long lExpire )
{
long l= DateTime.Now.Ticks;
double d= (double)l / lExpire;
string s= string.Format( "RegSucced( '{0}', {1} ), {2}, {3}", lclPrfUri, lExpire,
new TimeSpan( lExpire * TimeSpan.TicksPerSecond )
.ToString( "d\\.hh\\:mm\\:ss" ), d );
..
}
But i'm getting lExpire values in the range of 1.5 trillions (1'541'195'345'242)!
As i saw it constantly growing with time, i thought it might be related to Ticks, so i exposed both and gathered the following statistics (H == T + 1 hour -- expected expiration):
# DT.Now.Ticks (T) lExpire (E) T/E ratio T+36000000000 (H) H/E ratio
1 636767624266839520 1541183611836 413167.918 636767660266839520 413167.941
2 636767669188704010 1541188122398 413166.738 636767705188704010 413166.761
3 636767670260843180 1541188229643 413166.710 636767706260843180 413166.733
4 636767670974718350 1541188301027 413166.691 636767706974718350 413166.715
5 636767693193745790 1541190522922 413166.110 636767729193745790 413166.133
And the ratios look surprisingly consistent, though the magic of 413166 escapes me.. And from that lExpire looks more like a reference to a point in time, than an interval, no?
But according to docs i should get 3600 without any scaling factors, right? What is going on??!
UPDATE (2019-Jan-25)
Finally got closer to an answer. Digging through Android source files (e.g. https://android.googlesource.com/platform/frameworks/base/+/431bb2269532f2514861b908d5fafda8fa64da79/voip/java/com/android/server/sip/SipService.java) i found the following fragment:
#Override
public void onRegistrationDone(ISipSession session, int duration) {
if (DEBUG) Log.d(TAG, "onRegistrationDone(): " + session);
synchronized (SipService.this) {
if (notCurrentSession(session)) return;
mProxy.onRegistrationDone(session, duration);
if (duration > 0) {
mSession.clearReRegisterRequired();
mExpiryTime = SystemClock.elapsedRealtime() + (duration * 1000);
..
SystemClock.elapsedRealtime() returns milliseconds since boot, including time spent in sleep.
Time in UNIX/Linux/Java is kept as number of seconds since epoch (1970-01-01T00:00:00Z).
Wikipedia's page shows Current Unix time as 1548450313 (2019-01-25T21:05:13+00:00), which is only a 1000 times (s-to-ms multiplier!) different in range from lExpire values i observe. The formula for mExpiryTime in the last line kinda gives hope.. "Eureka!"?
Let's check if they conform to "# of ms since epoch" theory:
DateTime dtEpoch = new DateTime( 1970, 1, 1, 0, 0, 0, DateTimeKind.Utc );
void ISipRegistrationListener.OnRegistrationDone( string lclPrfUri, long lExpire )
{
DateTime dt = dtEpoch.AddMilliseconds( lExpire ).ToLocalTime( );
string s= string.Format( "RegSucced( '{0}', {1}, {2} )", lclPrfUri, lExpire,
dt.ToString( "yyyy-MM-dd HH:mm:ss.fff" ) );
..
}
Yesterday's screenshots - with that addition (magenta arrows mark exposed values):
As you can see, the difference between lExpire converted into time and DateTime.Now (captured in the log) is negligible - in ms range!
I actually like the idea of being given an expiration moment instead of duration (which need to be added to an undefined starting point). Was about to answer my question..
But still, there are follow-up unresolved mysteries:
Why documentation says the argument is duration in seconds?
Xamarin may be just copying Android docs, but the source is way wrong!
Is this really how lame Android devs are? Reckon that should be rethorical ((..
Does anybody care that requested expiration period may be trumped [down] by PBX /SIP server, and thus they have to re-register more often?
All calls to .onRegistrationDone(session, duration) in the source files specify duration, not mExpiryTime.
There are constant definitions (EXPIRY_TIME = 3600, SHORT_EXPIRY_TIME = 10, MIN_EXPIRY_TIME = 60) and comparisons of duration to these..
Range of values is drastically different between the two (3600 vs 15 trillion).
How/where does mExpiryTime (expiration moment) make it into the argument of my method?
ms since boot and s (or ms) since epoch are still very different, what makes that adjustment?
and finally, asking a 1 hr expiration and receiving it in the OK reply from SIP server, i expect that to be reflected here too, so lExpire should be 1 hr in the future, not now!!
Any ideas?
I am trying to add one day to calendar date but i am getting wrong output.
Below code i am using.
var cal2= Calendar.getInstance()
cal2!!.timeInMillis=cal.timeInMillis
Log.e("Time1",""+cal.timeInMillis);
cal2.add(Calendar.DATE, 1)
Log.e("Time2",""+cal2.timeInMillis);
Time1: 1526478465( Wednesday, 16 May 2018 19:17:45)
Time1: 1612878465(Tuesday, 9 February 2021 19:17:45 )
Assuming your cal.timeInMillis has proper value (say today's date), your code works fine:
var cal = Calendar.getInstance() <-- Assumption
var cal2 = Calendar.getInstance()
cal2!!.timeInMillis=cal.timeInMillis
println("Time1: "+cal.timeInMillis);
cal2.add(Calendar.DATE, 1)
println("Time2: "+cal2.timeInMillis);
Running above code gives following output:
Time1: 1527159971747 (Thursday, May 24, 2018 11:06:11.747 AM)
Time2: 1527246371747 (Friday, May 25, 2018 11:06:11.747 AM)
You’re somehow confusing seconds and milliseconds since the epoch. 1 526 478 465 is seconds. If you treat them as milliseconds, you get January 18, 1970 4:01:18 PM UTC. If you add 1 day to that, you get the next value you mention (I got 1 612 878 000, it comes close). When in turn you interpret 1 612 878 465 as seconds, you get February 9, 2021 1:47:45 PM UTC. This is the same as the date-time you mention, Tuesday, 9 February 2021 19:17:45, if I assume you’re at offset +05:30 (like Asia/Kolkata or Asia/Colombo time zone).
Since there are 1000 milliseconds in a second, your confusion has caused you to add 1000 days to your date instead of 1 day.
Tip: 10 digit values are usually seoncds. 13 digit values are usually milliseconds.
time Range picker to select time range, with hours mins and seconds android
Is there any library which supports seconds also
the only one i found was
https://github.com/tittojose/TimeRangePicker
but it does not support seconds
use this,
int time=(picker.getCurrentMinute() * 60 + picker.getCurrentHour() *
60 * 60) * 1000;
SimpleDateFormat format = new SimpleDateFormat("HH:mm:ss");
String formatted = format.format(time);
I have a small issue with different Android devices returning the image taken date time-stamp in either seconds or milliseconds. I use a Intent.ACTION_PICK and then use a content resolver to query the result.
I am finding that MediaStore.Images.ImageColumns.DATE_TAKEN column returns in seconds on a Samsung Galaxy J7, but is milliseconds on a Samsung Edge 7. How can I determine which one a device uses?
As you're dealing with photos taken by an Android device, we can assume that there won't dates before the year 2000.
The timestamp for 2000-01-01T00:00Z is 946684800 seconds (or 946684800000 milliseconds). So, if the value is below 946684800000, then you can assume it's in seconds.
Of course you can be more precise and instead of year 2000, you can use dates after the first Android version release, or even discard older versions and consider the last N versions (N can be as arbitrary as you want). Here's the timestamp for the Android versions release dates (all dates based on this link - time was set to midnight and offset is UTC):
2008-09-23T00:00Z: 1222128000000 milliseconds
2009-02-09T00:00Z: 1234137600000 milliseconds
2009-04-27T00:00Z: 1240790400000 milliseconds
2009-09-15T00:00Z: 1252972800000 milliseconds
2009-10-26T00:00Z: 1256515200000 milliseconds
2010-05-20T00:00Z: 1274313600000 milliseconds
2010-12-06T00:00Z: 1291593600000 milliseconds
2011-02-22T00:00Z: 1298332800000 milliseconds
2011-10-18T00:00Z: 1318896000000 milliseconds
2012-07-09T00:00Z: 1341792000000 milliseconds
2013-10-31T00:00Z: 1383177600000 milliseconds
2014-11-12T00:00Z: 1415750400000 milliseconds
2015-10-23T00:00Z: 1445558400000 milliseconds
2016-08-22T00:00Z: 1471824000000 milliseconds
Well milliseconds would be 1000 times larger. And all timestamps on the device should be relatively recent- in the past few years. So if the number is above say 10 billion, its milliseconds. If its below, its seconds. This test will work for the next century or so.
I'm getting a data which contains a certain number.
I need to find how many hours, minutes and seconds it stands for.
for example:
I'm getting the number 248 which means:
00 hours : 04 minutes : 08 seconds
Any ideas would be really apprieciated!
Determine hours, minutes and seconds like this:
int hours = (int) (time / 3600);
int minutes = ((int) (time / 60)) % 60;
int seconds = time % 60;
Alternatively, you can determine minutes like this once you know the hours:
int minutes = (int) ((time - hours * 3600) / 60));
You need to multiple it to milisec.
Like 248*1000;
Then Date d = new Date(248*1000);
And youll have data object.
d.getHours(). for example
also you can use SimpleDateFormat. Which can format data with some pattern and output it to string
Like yyyy-MM-hh HH:mm
you have to define first, how this number is build up, e.g. why it can not stand for
00 hours, 02 minutes and 48 sseconds