if this calculation is used in cam, it will always end up on a multiple of [interval] seconds.but not with a float.
repeat if os.difftime(os.time(),t1)>=0 then t1=os.time()+interval
math.floor worked for me, however not with the os.time calculation.
but did with sys.gettimeofday()
is there a variable that only has the time of day in seconds? (preferrably UTC)
If you can clarify what didn't work and how it failed, I might be able to help
This exposes the (confusingly named) gettimeofday libc function. It returns two integers: A timestamp similar to os.time, followed by the microseconds fraction.
On Windows and Linux, os.time and gettimeofday work in unix time, more or less.So you if you want to know how many seconds you are into the day, you could get the unix time value for 00:00 in the current day and subtract that from the current time.
You can use *t or !*t with os.date to get a table representing the current date+time (or a specified unix time) in local or UTC time respectively. You can get a timestamp from a similarly constructed table (in local time only) using os.date.use !return os.date('*t') to see the field nameschdku.ts_get_offset returns the local timezone offset from UTC in seconds.
it is not that important since it works with sys.gettimeofday()
but if you replace currentime in this code with os.time and secs with any interval (in seconds) it will give a one digit fraction in the result, if you use sys.gettimeofday() it doesn't.......in theory there is no difference between theory and real life, in real life there is.Code: [Select]next_shot_moment=math.floor((currenttime+secs)/secs)*secs
!local t1=os.time() local t2=sys.gettimeofday() local secs=86400 local r1=math.floor((t1+secs)/secs)*secs r2=math.floor((t2+secs)/secs)*secs return r1,os.date('!%c',r1),r2,os.date('!%c',r2)=1657411200,"07/10/22 00:00:00",1657411200,"07/10/22 00:00:00"
after you helped me through that ordeal of me compiling i'm using 1167....will take a few revisions before i try that again
maybe i'll figure it out when i get back to that, but math.floor should never end up with a fraction, that's the whole point isn't it?
i have some trouble that one of the 2 cams i use for this setup is a s110-103a and because that has no dual support yet it's a fair bit slower than the other s110-102b.but since i'm still testing my software changes i feel like i'm overasking philmoz by requesting yet another tailor made build before i have made it into a working rig.
Started by kennyb03
Started by Lebeau
General Discussion and Assistance
Started by Karmaschinken
Started by reyalp
Started by alex73
RAW Shooting and Processing