This aims to be a complementary answer to Doc Brown, and also to respond to unanswered comments of Dinaiz that are still related to the Question.
What you probably need is a framework for doing DI. Having complex hierarchies does not necessarily means bad design, but if you have to inject a TimeFactory bottom-up (from A to D) instead of injecting directly to D then probably there's something wrong with the way you are doing Dependency Injection.
A singleton? No thanks. If you need only one istance make it shared across your application context (Using a IoC container for DI like Infector++ requires just to bind TimeFactory as single istance), here's the example (C++11 by the way, but so C++. Maybe move to C++11 already? You get Leak-Free application for free):
Infector::Container ioc; //your app's context
ioc.bindSingleAsNothing<TimeFactory>(); //declare TimeFactory to be shared
ioc.wire<TimeFactory>(); //wire its constructor
// if you want to be sure TimeFactory is created at startup just request it
// (else it will be created lazily only when needed)
auto myTimeFactory = ioc.buildSingle<TimeFactory>();
Now the good point of a IoC container is that you don't need to pass time factory up to D. if your class "D" need time factory, just put time factory as constructor parameter for class D.
ioc.bindAsNothing<A>(); //declare class A
ioc.bindAsNothing<B>(); //declare class B
ioc.bindAsNothing<D>(); //declare class D
ioc.wire<D, TimeFactory>(); //time factory injected to class D
ioc.wire<B, D>(); //class D injected to class B
ioc.wire<A, B>(); //class B injected to class A
as you see you inject TimeFactory only once. How to use "A"? Very simple, every class is injected, builded in the main or istantiated with a factory.
auto myA1 = ioc.build<A>(); //A is not "single" so many different istances
auto myA2 = ioc.build<A>(); //can live at same time
every time you create class A it will be automatically (lazy istantiation) injected with all dependencies up to D and D will be injected with TimeFactory, so by calling only 1 method you have your complete hierarchy ready (and even complex hierachies are solved this way removing A LOT of boiler plate code): You don't have to call "new/delete" and that's very important because you can separate application logic from glue code.
D can create Time objects with informations that only D can have
That's easy, your TimeFactory have a "create" method, then just use a different signature "create(params)" and you are done. Parameters that are no dependencies are often resolved this way. This also remove the duty of injecting things like "strings" or "integers" because that just add extra boiler plate.
Who creates who? IoC container creates istances and factories, the factories creates the rest (factories can create different objects with arbitrary parameters, so you don't really need a state for factories). You can still use the factories as wrappers for the IoC Container: generally speaking Injectin the IoC Container is very bad and is the same of using a service locator. Some people solved the problem by wrapping the IoC Container with a factory (this is not strictly necessary, but has the advantage that the hierarchy is solved by the Container and all your factories becomes even easier to maintain).
auto istance = ioc->build<myType>(); //this code's agnostic to "myType" hierarchy
istance->setParams(params); //the customization you needed
Also don't abuse dependency injection, simple types can just be class' members or local scoped variables. This seem obvious but I saw people injecting "std::vector" just because there was a DI framework that allowed that. Always remember Demeter's law: "Inject only what you really need to inject"