I tested it and it works for most scenarios, except negative fraction numbers , like -1.5.
Here is the fix:
utc_min=abs((offset-int(offset))*60);

@Alex,

I get old .... I will make the change and issue the pull request.
By the way, any idea where comes the round up of offset (When Offset of location it n,75 Indi considers offset as n,8 ?

@Norikyu,

may be setting time source in Kstars solves your problem.
I cannot test, have no time source in OnStep,

Select "Mount Updates Kstars"

Pull request issued, waiting for merge in master:

Current versions:
OnStep 4.24p
INDI Library: 1.9.5
indi_lx200_OnStep 1.15
kstars Version 3.5.8 Stable

Wonderful!

Not sure about this particular issue, but in general, floating point math is very imprecise.
You may get some really unexpected results, e.g. instead of 2x2=4 you may get 3.999999008
The whole idea of pushing floating number back and forth for this use case is totally wrong and probably requires much bigger refactoring.

Thank you for the hint.
But, I couldn't solve that.

I tried setting "Time & Location Updates" in the KStars INDI option to "Mount updates KStars".

When I tried it with Celestron AVX, I can get the location information and date and time of the AVX controller settings. And KStars will display the stars where the AVX is placed.

For OnStep Driver, the time will always be "UNIX Epoch-1 second", so KStars will display the wrong stars.
It looks like it is failing to get the internal time of OnStep.
Does the INDI OnStep Driver not support getting the OnStep internal time?

@Alex,

I don't think this is due to Floatint Point Math but rather to some obscure ftoa() and atof() somewere between kstars / Ekos and Indi but I am not able to track it ...
By doing tests if I enter for example 3,75 into control panel everything is ok.
If I enter the same value via Geographic settings I get 1,8 in control panel and Indi

So must be in Ekos / Kstars but I can be wrong as many times

@Norikyu,

It is not OnStep that manages time and location but Indi so normally this should work.

I made the following test.
1) I did run Onstep as alway just to make sure Time / Location are as usual.
2) Disconnected OnStep and closed Kstars
3) Set my system location to Panama
4) Opened Kstars and set the Geographic Location to Panama
5) You can see Time in Time1.pgn
6) Started OnStep Driver see Time2.pgn
7) Connected OnStep see Time3.png

As you can see as soon I connect OnStep time is updates with Firmware Time

I think you are right. But it didn't work in my environment.
I debugged and found the cause.

lx200_OnStep.cpp line 4790
Processing of the LX200_OnStep :: sendScopeTime () function.

mktime is returning -1 and time_epoch is calculated with the wrong value.
The cause is that ltm is being used uninitialized and ltm.tm_isdst is set to the wrong value.
Initializing ltm cleared the error.

This problem happens by accident, but it can happen to anyone.
Similar errors are possible with other sources.
The source code using the mktime function is as follows.

indi-master/drivers/telescope/ioptronHC8406.cpp
indi-master/drivers/telescope/lx200_OnStep.cpp
indi-master/drivers/telescope/lx200_TeenAstro.cpp
indi-master/drivers/telescope/lx200pulsar2.cpp
indi-master/drivers/telescope/lx200telescope.cpp
indi-master/drivers/telescope/rainbow.cpp
indi-master/tools/evalINDI.c

Post deleted

@Norikyu,

thank you for the debugging and solution proposal.
Since it involves not only Onstep but also others drivers we should treat the complete set.
Do you take care of making the changes and issue the pull request?

If not I will see what I can do and by when.

By the way, could you please identify which system and versions you are running (OS, Kstars, OnStep, Indiserver)

@alex

Is it not one of the following that is failing as it is meant to initialize ltm in the end ?
if (getLocalTime(ctime) == false)
{
LOG_WARN("Could not obtain local time from mount!");
return false;
}

if (getLocalDate(cdate) == false)
{
LOG_WARN("Could not obtain local date from mount!");
return false;
}

// To ISO 8601 format in LOCAL TIME!
char datetime[MAXINDINAME] = {0};
snprintf(datetime, MAXINDINAME, "%sT%s", cdate, ctime);

// Now that date+time are combined, let's get tm representation of it.
->>>>>> if (strptime(datetime, "%FT%T", &ltm) == nullptr)
{
LOGF_WARN("Could not process mount date and time: %s", datetime);
return false;
}

// Get local time epoch in UNIX seconds
time_epoch = mktime(&ltm);