core.getDate() bug

Feedback
2012-05-23
2012-10-09
  • Rich Schottler
    Rich Schottler
    2012-05-23

    Hello, sorry for posting here, but don't want launchpad account. Bug #578101
    has not been fixed satisfactorily in 0.11.2. The utc time is fine, but local
    time returns the computer clock time, rather than the time of the location set
    in the sim. In other words, if I live in the US Mountain timezone, but have
    the sim set to Cape Town, South Africa, I get back my local mountain time
    rather than UTC+2hrs.

    One other thing, in the scripting API, it would be nice to be able to get the
    sim location longitude and latitude. Either as a function of core, or by
    access to LocationMgr.

    Thanks!

     
  • Alexander Wolf
    Alexander Wolf
    2012-05-24

    The utc time is fine, but local time returns the computer clock time

    This is correct. Stellarium get local time from computer, not from location.

    One other thing, in the scripting API, it would be nice to be able to get the
    sim location longitude and latitude. Either as a function of core, or by
    access to LocationMgr.

    core.getObserverLocation() & core.setObserverLocation()?

     
  • Rich Schottler
    Rich Schottler
    2012-05-24

    Thanks for the answers, unfortunately, not exactly what I was looking for. I
    understand that getDate("local") retrieves the computer time, but this is not
    ideal in-simulation, especially from a scripting standpoint. In a script, I
    need to know the correct clock time for the simulation location and the
    correct UTC in order to calculate the correct time offset for the sim
    location. If my in-sim location is set different than my computer clock, this
    gives an incorrect time offset. I figured out a workaround, but I shouldn't
    need one for retrieving the time offset of the in-sim location.

    Ideally, getDate("local") should get the in-sim location date and time. I
    would suggest changing getDate("local") to this behavior, and adding
    getDate("computer") to perform the existing behavior.


    getObserverLocation() retrieves only the location name (as a QString), it does
    not retrieve other information about the location like latitude and longitude.

    I would suggest changing getObserverLocation() to retrieve a QVariantMap with
    at least the first 7 public attributes of StelLocation.


    And while I'm at it ... ;-)
    It would be very nice to open up a public slot for
    (QVariantMap)core.getSelectedObject() that returns various data about the
    currently mouse-selected sky object.
    Aaaannddd ... it would be very nice to allow some sort of scripted
    handleKeys() function definition (and handleMouseMoves, handleMouseClicks, and
    handleMouseWheel for that matter) that override StelMovementMgr (or other)
    versions.


    just call me "wish-lists-r-us" :D

     
  • Rich Schottler
    Rich Schottler
    2012-06-04

    Thanks Alex! As I don't have time to help out with Stellarium myself (and I
    haven't done C in a loooonnnggg time anyway), that's great news. Ya'all are
    doing a fantastic job!

     
  • Rich Schottler
    Rich Schottler
    2012-06-08

    Hi Alex - got another wish for you.

    core.getObjectPosition returns a QVariantMap of various location data for an
    object. That's great, except that the altitude value is always apparent
    (corrected for atmospheric refraction), regardless of the state of
    StelSkyDrawer.getFlagHasAtmosphere(). It would be nice to have the geometric
    altitude available, maybe as "altitude-geom" or some such. I didn't check
    RA/dec, but I'm guessing they have the same issue.

    Thanks!

     


Anonymous


Cancel   Add attachments