Daylight: Date and Time anomalies

[Steve_Curley]

Playing with the Solar Date and Solar Time properties of the Daylight system, I've come across a couple of anomalies. These may well be me being dim (not unheard of) or Max is being inconsistent/incorrect in the representation of these values.

Taking the time first, if I create a script variable and assign the Solar Time to it, the value returned agrees with the Help - Number of seconds since midnight. If, however, I assign it to a Track instead then the value is different - it returns a Float value where the Integer portion is the hour and the fractional part is a decimal fraction of an hour (45 mins would be 0.75). The two values are actually the same time, but they require different calculations to extract the hours, minutes and seconds.

The Solar Date is even worse. Assigning as either a Controller or a Track returns the same value, which is good, but that value would appear to be wrong. The MXS help clearly states that the returned value is a number of days offset from Today. As you can see from the image, it thinks that Today (June 29, 2008) is 8 days from Today. Something not quite right, methinks.

Additionally, having that date as a offset is completely useless. There doesn't appear to any built in Date conversion functions. There's one which returns Today's date as an array of values, but you can't pass any other date to it. To my mind all Dates should be represented as a "number of days since" (01/01/1980 probably, though there are other dates which can be used as well). This would need conversion functions both to and from that value - then the "offset" would have some use.

</me prepares to be shot down in flames>

Attached scene is Max 2009. The script is attached to Dummy01 Rotation.

9401_CFUth41eefhN1LOOlQnJ.zip

[Anonymous]

Oh, the help is wrong 🙂

The Solar_Date is the offset from the SUMMER SOLSTICE, June 21st. That's why the offset was 8.0 on 29th of June, and today is already 9.0.
When you create the controller, the offset is set to 0.0 which gives you June 21st of the current year automatically.

Thanks for noticing, will be fixed for the next version.

[Steve_Curley]

Thanks Bobo - I knew one or the other (Max or the Help) was wrong - or I'm seeing things 😮

Any comment on the time values being a different format (albeit the same actual time) and the "offset" issue in general?

[Anonymous]

Oh, the help is wrong 🙂

The Solar_Date is the offset from the SUMMER SOLSTICE, June 21st. That's why the offset was 8.0 on 29th of June, and today is already 9.0.
When you create the controller, the offset is set to 0.0 which gives you June 21st of the current year automatically.

Thanks for noticing, will be fixed for the next version.

hello bobo - resurrecting an old thread here - the behavior of the daylight system in 2009 is actually slightly different still than what is described - the "0" date for the solar_date is the summer solstice of the YEAR IN WHICH THE SYSTEM WAS CREATED! So if you set your system date back in time to any day in 2008, 0 will be june 21, 2008. if you open a file from a long time ago, 0 might be june 21, 2005. this is pretty troublesome!

more troubling is that i can't seem to get the solar_time values as they are described in the help. there is even an example script in the help which claims to convert the solar_time from seconds into hh:mm:ss, but it doesn't work properly since $daylight01.controller.solar_time returns a value which ONLY seems to represent the hours as an integer. i'm confused. when used with parameter wiring, it seems to work, but within a normal script or in the listener, all i get is something like this :

$daylight01.controller.solar_time
13

or

$daylight01.controller.solar_time as float
13.0

when the time is something like 12:20:10.... and the script which claims to convert the values gives me this not-so-useful array!

TimeFromSolarTime()
#(0, 0, 12)

any suggestions? i've created a small script which uses the dotnet date objects to convert the solar_date value into year, month, and day, and then puts it into the value of a standard text object through a variation on the dynamic text example script. not so useful without a better indication of the time than just hours though.... thanks in advance!

[Anonymous]

ok, looking on cgtalk i found this bit - if you use

$daylight01.controller.solar_time.controller.value instead of $daylight01.controller.solar_time then you get a float which contains the full time expressed in hours - e.g. 12.3333 or 12.4515 etc.

that works for my purposes - but the help is still wrong!

[Anonymous]

ok, looking on cgtalk i found this bit - if you use

$daylight01.controller.solar_time.controller.value instead of $daylight01.controller.solar_time then you get a float which contains the full time expressed in hours - e.g. 12.3333 or 12.4515 etc.

that works for my purposes - but the help is still wrong!

Here is the proposed new example for the Help:

fn TimeFromSolarTime daylightSystem =
(
local solar_time = daylightSystem.controller.solar_time.controller.value 
local hrs = int solar_time 
local min = int ((solar_time-hrs)*60)
local sec = int ((solar_time-hrs-min/60.0)*3600 + 0.5) 
#(hrs,min,sec)
)

TimeFromSolarTime $Daylight01

[pfbreton]

for some reason thereis a bug when the daylight system is driven by a scripted controller with this example.


--time
--for some reason, when the controller of the daylight system is a scripted controller, returned values are 3600 times too large.
--checking for that case allows us to adjust the result of the function consequently
local intVal = 1
if classof dlSystem.controller.Solar_Time.controller == float_script do intVal = 3600

local solar_time = dlSystem.controller.solar_time.controller.value / intVal
local hrs = int solar_time -- full hours in the solar_time value
local min = int((solar_time-hrs)*60) -- full minutes in the difference between the full time and the full hours
local sec = int((solar_time-hrs-min/60.0)*3600 + 0.5) -- full seconds in the rest of the value

[pierre]

Thanks for this bobo

But the help files are still out of date and wrong.