What are the rules for DSTIME if a property type is a class?

If that base class has a property that is another class, do I have to add the DSTIME parameters to that secondary class? 

No. DSTIME needs to be defined only for a base class of a cube (fact table class). 

It works like this:

1. During the compilation if DSTIME parameter is present %Save/%Delete methods would write the fact class, id and action into ^OBJ.DSTIME global
2. Cube synchronization job would iterate over this global but only over fact class and process them accordingly
3. %PurgeDSTIME from %DeepSee.Utils class would clear all processed records in ^OBJ.DSTIME global and all records that are not from fact classes

You don't need to set DSTIME parameter in the secondary class.

However, OBJ.DSTIME and SynchronizeCube does not see changes in objects of secondary class.

That is the case mentioned as

The changed record is not in the extent of the base class used by the cube.

in documentation (http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...)

For example, let's say that you have cube Person based on Sample.Person class.

And that class Sample.Person has property Job that references persistent class Sample.Company.

If you just modify object of Sample.Company as follows:

set p = ##class(Sample.Company).%OpenId(100)
set p.Name = "New Company Name"
write p.%Save()

Then this change will not be seen by SynchronizeCube and you'll need to update cube manually:
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

Adding DSTIME parameter to the Sample.Company does not help as original cube Person is not based on this class.