How to Join 2 tables if datetime diff is within range?

Question

Hi, problem figuring out how to join tables if the datediff ? is within range.  
There are 3 tables  a main table then 2 sub tables, these are measurements with a date/time value.  Im trying to take the datetime entries from the 2 sub tables and match them, then add  them to the main table
subtable1 has SampleID, datetime, 
subtable2 has TesterID, datetime
maintable has SampleID, datetime, TesterID, datetime
so the maintable would always have the sampleID value and datetime regardless.  but it would only JOIN the testerID and its datetime, only IF these 2 datetime values were close, and the datediff interval was set to 1 second.
 its a function call that fills the main tables matching columns but only if the testerIDs datetime is close to the sampleIDs time????
thanks

Answer 1

Please post DDL, so that people do not have to guess what the keys, constraints, Declarative Referential Integrity, data types, etc. in your schema are. Learn how to follow ISO-11179 data element naming conventions and formatting rules. Temporal data should
use ISO-8601 formats. Code should be in Standard SQL as much as possible and not local dialect. 
This is minimal polite behavior on SQL forums. Thanks for making us do your typing and DDL for you :( 
>> There are 3 tables; a main table then 2 sub tables, <<
Really? Main table? Sub-tables? There are no such terms in SQL. Trust me on that; I helped with the Standards :) We have referenced referencing tables in the DRI model of SQL. 
>> these are measurements with a date/time value. << 
++Both of them, the measurementID and otherID  have a millisecond timestamp, the goal is to associate these 2 measurements, they are coming from different systems.  
Do you really need the full timestamp down to nanoseconds and not just a DATE? Oh, we also have no sample data :( So we have to guess at precision, constraints, keys, etc. 
See why we need DDL? Is this relationship 1:1, 1:M OR N:1? My guess is that a tester can do many samples, but a sample has only one tester. And what were those two timestamps? Not redundant copies from the referenced tables!! That would non-normalized. 
>> so the Sample_Tester_Relationship would always have the sample_nbr value and <something>_timestamp regardless. But it would only JOIN the tester_id and its DATETIME, only IF these 2 DATETIME values were close, and the DATEDIFF interval was set
to 1 second. <<
No, you do not do a JOIN inside a base table. That is VIEW.
>> It is a function [sic: procedure, Functions return scalar values] call that fills the main tables matching columns but only if the tester_id DATETIME is close to the sample_id time? <<
No sample data, no sample code and no business rules about ties. Here is my final guess at normalizing this problem: 
CREATE TABLE Samples
(sample_nbr CHAR(12) NOT NULL PRIMARY KEY,
CREATE TABLE Testers
(tester_id CHAR(10) NOT NULL PRIMARY KEY,
CREATE TABLE Sample_Tester_Relationship --- needs a real name!
(sample_nbr CHAR(12) NOT NULL PRIMARY KEY
 REFERENCES Samples
  ON UPDATE CASCADE
  ON DELETE CASCADE,
 tester_id CHAR(10) NOT NULL
 REFERENCES Testers
  ON UPDATE CASCADE
  ON DELETE CASCADE,
 PRIMARY KEY (sample_nbr, tester_id),
 tester_timestamp DATETIME2(1) DEFAULT CURRENT_TIMESTAMP NOT NULL,
 sample_timestamp DATETIME2(1) DEFAULT CURRENT_TIMESTAMP NOT NULL,
 CHECK (ABS (DATEDIFF (SECOND, tester_timestamp, sample_timestamp) <= 1) );
Most of the work in SQL is in DDL, not DML. 
I will try this out and advise.
--CELKO-- Books in Celko Series for Morgan-Kaufmann Publishing: Analytics and OLAP in SQL / Data and Databases: Concepts in Practice Data / Measurements and Standards in SQL SQL for Smarties / SQL Programming Style / SQL Puzzles and Answers / Thinking in
Sets / Trees and Hierarchies in SQL
Dear Celko
thank you for this constructive feedback, clearly you're an expert and I am going to be better for following this advice.  In the 1970s I was told to avoid going into software because Japan had invented a way for computers to write their own code, so
programmers would be out of a job and the field would be a dead-end.  I didnt formally begin training in sw until the 90s.  SQL is one of those last frontiers i never trained in.  but now Im trying to learn and find anything i can read to absorb
it.
I posted in laymans words because i thought thats how you experts would prefer it described, clearly not.  I will now take the time to read each reference to the standards...