B4X:
Sub convert_seconds2Ticks(seconds As Long) As Long
seconds = seconds * DateTime.TicksPerSecond 'convert seconds to ticks!
Return seconds
End Sub
-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Android Code Snippet [B4X] convert seconds to ticks
- Thread starter Alexander Stolte
- Start date
- Similar Threads Similar Threads
DateTime.TicksPerSecond is always = 1000 
Ticks are just milliseconds.
Like MinutesPerHour = 60
Ticks are just milliseconds.Like MinutesPerHour = 60
For B4X, and perhaps most of the Unix universe generally, that might be the case. But 18.2 ticks per second (2^16 per hour) is another common value, and many early computers that derived their timing from the video subsystem had ticks at the video frame rate eg 60 Hz. I have seen ticks that are a binary fraction of a second eg 128 ticks per second, and ticks that are based on the mains power frequency, which in most countries is a convenient and accurate timebase.
Generally speaking, ticks whatever time unit/period the operating system or program uses to measure time.
For Linux based OS (or Java virtual machines), i think, we always talk about TicksPerSecond = 1000. Isn't it ?
I agree with you this seems currently true, and that it is unlikely to change (ironically, probably because it would break too many programs that have assumed it will never change and have thus hardcoded it to 1000).
But technically: no. The fact that the .TicksPerSecond conversion factor is provided suggests that the way is being left open for it to be different if need be, eg if the system clock is not a multiple of 1000 Hz. I have seen what manufacturers will do to save a cent on a component, especially on large production runs, and crystals are a prime target for this because near-enough-is-good-enough, right?
I think I got triggered by the word "always" that makes it sound like there is some immutable relationship between ticks and milliseconds, and that the two are interchangeable, but... they're not. It is similar to saying that litres and kilograms of water are the same, or that mass and weight are the same thing - in typical day-to-day life experience they are - but not always. And sometimes the difference matters, and that is when we don't want people thinking that eg ticks and milliseconds are the same thing.
You have an excellent memory. I assume you're referring to the same 1950's proposal by the USA that was part of their continued efforts to sabotage SI units and thus maintain scientific dominance by sowing disarray amongst the rest of the world (except Liberia and Burma). But happily, this proposal died when it was pointed out that the definition would still need to be made at the same pressure and temperature triple-point as for water, and even the Americans agreed that having coffee at such a low temperature was a bit much to swallow.We're programmers, shouldn't it be litres and kilograms of coffee are the same ?
For anybody who doesn't believe that, consider this interesting fact: when airline pilots calculate the fuel required for long trips, the equation includes an allowance for the fact that the airplane's apparent weight (ie, lift force required) varies depending on the direction in which it is flying. Planes flying east weigh less than planes flying west. How crazy is that?
One of the above two paragraphs is true; the other paragraph, I just made it up. Although... it could be true - it's certainly plausible.
Prevailing winds are from the west toward the east in the middle latitudes between 30 and 60 degrees latitude, so you always have a tailwind, thus requiring less fuel.
Nice try, that is an additional advantage, but... the difference in apparent weight happens even if there is no wind bias, and the effect is greater closer to the equator.
