have you checked out the DateTimePicker component located in the Win32 palette, or if you need a database aware version of the datetimepicker, you could download and install this http://delphi.about.com/library/code/ncaa042004a.htm
I think using one of those components would be the simplest solution.
As to having one form "communicate" with another form, it's not difficult, but there are some issues to be aware of.
To deal with the circular reference issue, the format of a *.pas file offers two locations to have a "uses" clause. The first is right after the interface directive and the other is right after the implementation directive.
You can put both dependent units in the uses clause after the implementation directive of their respective units, or you can put one in the interface section and the other in the implementation section. Either works
Once you have the units listed in the uses clause, then the variables, function and procedure methods declared in the other form's public section should be available to the "other" form. You could declare a public function to set, for example, Edit1.Text to a value.
TForm1 = class(TForm)
procedure SetEditText(str: String);//add this
procedure TForm1.SetEditText(str: String);
Edit1.Text := str;
From your other form, after adding MainForm to the uses clause, you would be able to use it:
MainForm.SetEditText('This text will be put in Edit1');
As far as issues with having two forms communicate, obviously both forms would have to exist for them to communicate. Not such a big deal if a child form is talking with the main form (to initiate communications, the child would have to exist, and the main form must exist for the application to exist), but if two child forms, or a main form needs to communicate with child form, then you run the possibility of attempting to access something that doesn't exist. That would cause an access violation, possibly crashing your application.