[API] ShadowInfo

[Dan Rathbun]

[API BUG] class ShadowInfo

ShadowInfo['SunRise']
and
ShadowInfo['SunSet']

The time returned (hour actually) within the Time class object for BOTH attributes are off by 1 diference to UTC (GMT).

It appears within the code that the difference between localtime and GMT is subtracted twice instead of once.

Example: Today, ShadowInfo['SunRise'] tells me that the Sun was supposed to rise a hour ago (at 2:07 AM local,) but I can attest that it's still dark night outside (and there's nothing on the news about the Sun burning out.)
The "real" local SunRise time for today, here (Melbourne, FL) is 6:07 AM (we are GMT-5 normally, but GMT-4 when DaylightSavingTime is active.)

Interestingly, the Shadow Settings dialog displays the correct SunRise and SunSet times beneath the "Time" slider

[Dan Rathbun]

More info:

ShadowInfo['ShadowTime'] returns incorrect hours.

ShadowTime displays correctly in the dialog (on the time slider, but ShadowInfo['ShadowTime'] seems to return a time which is the "SliderTime" minus the user's OS system (time zone,) difference to GMT (taking Daylight Savings Time into account,) regardless of where the model's geolocation is. The same error occurs whether the model is located in Boulder, Colorado or Melbourne, Florida (My local location.) Since my computer is located at GMT-5 hours (or GMT-4 hours during daylight savings time,) the time returned by ShadowInfo['ShadowTime'] is currently (on DST,) always 4 hours less than the "SliderTime" in the Shadow Settings inspector dialog.

[wehby]

Dan,

Try modifying your ShadowTime with ".utc" to fix the issue.

Please see one of these threads for more info:
http://groups.google.com/group/sketchupruby/browse_thread/thread/79f9988ab2149ec7/950074b80b134478?lnk=gst&q=wehby#950074b80b134478

http://groups.google.com/group/sketchupruby/browse_thread/thread/66977a5b79beba6e/655f563bece2c997?lnk=gst&q=wehby#655f563bece2c997

Regards,
wehby

[Dan Rathbun]

@wehby said:

Try modifying your ShadowTime with ".utc" to fix the issue.

Thanks, wehby!

I would characterize this as a workaround, and not a fix.
It results in the time zone being bogus (for the user's timezone,) and still there is no correlation to the model's location (which is often quite different then the user's location.)

It also brings up the issue of how do we get the model's time zone?
(We cannot at present, and what may be needed [in the future,] is a Sketchup::Location class, that has dedicated StateProvince and TimeZone attributes; as well as City, Country, and LatLong attributes. [The TimeZone constants are defined in the standard Ruby Date class.])

[wehby]

Hi Dan,

The time in relationship to the user's computer's time zone was pretty confusing for me until I adopted the habit to always put ".utc" after all my new time objects. The problem comes from Ruby (Class:Time), not SkRuby. Time.new creates a time object initialized to the current system time.
http://ruby-doc.org/core/classes/Time.html

The ShadowInfo class in SkRuby contains all of the location information. You can use it to set city, timezone offset, latitude and longitude.
http://code.google.com/apis/sketchup/docs/ourdoc/shadowinfo.html#methods
Although if you use Ruby to set the city, SU treats it as a custom locale and does not reference the locations.dat file to get the rest of the location information (meaning that you will also have to manually set the timezone offset, latitude and longitude). I guess it would be possible for a Ruby programmer to access the same locations.dat file to automate that process.

I hope that helps.

Regards,
wehby

[Dan Rathbun]

@wehby said:

I guess it would be possible for a Ruby programmer to access the same locations.dat file to automate that process.

It's just a comma-delimited text file. No problem there.

Format (sorted in left-right field order):
"Country", "City", Long, Lat, TZOffset

Long, Lat, TZOffset are Float (W Long neg; S Lat neg; TZOffset sign ref to UTC.)