In the scenario you describe, you should definitely be looking at multiple access points, preferrably dual band APs.
While coverage may be sufficient, coverage alone is no longer the primary consideration when deploying a wirelss network. Client capacity, channel utilization, signal quality, and reliability are much more important and multiple access points will help with all of these.
By using 3 (or more) APs on multiple channels (1, 6, and 11), you will in effect triple the amount of airtime (bandwidth) available on your wireless network.
Additionally, proper placement of the APs will provide clients a closer AP with stronger signal, which will be more resistant to noise in the RF environment. This will allow better signal-to-noise (SNR) ratios which will translate to the use of higher data rates and this results in more data transmitted per "timeslot".
I would recommend placing them 2/3 to 3/4 of the way from the center to the perimeter, spaced roughly evenly. Try to get them in or as close to the highest user denisity locations as possible (i.e. conference rooms, etc).
Finally, the additional access points will provide increased reliability. With a single access point, if it were to fail or reboot for any reason, this would create a disruption in service. Having multiple access points should allow for coverage to overlap, allowing service to remain (if degraded) when you have an access point down.
You can download the 802.11-2012 standard from the IEEE web page. On page 429 you can find the the information contained in the probe request body, none of which contain a time stamp.
However, you will note that the final element is defined as "Vendor Specific." It would be possible to add a time stamp in this this element. This would typically require that you modify the code of the driver on the client device. Any device not running your customized driver would not be sending this time stamp.
If you want the access point to recognize this and act on it, then you would need to modify the access point as well. If it would suffice for your needs, you would be able to view the contents of this element if you were doing something like a packet capture as probe requests are not encrypted.
Best Answer
The timestamp in a PCAP file is the time the traffic was observed by the capturing platform. It is meant to be wall-clock time to high accuracy. It is expected that not all platforms implement a high-accuracy wallclock time (eg, the platform may not run even NTP, let alone more accurate technologies). Furthermore it is convention that implementations which use some other zero-hour are permissible PCAP. For example, some of the scrubbers for sharing PCAP files will have the first packet be the zero-hour to avoid leaking the wallclock time the capture was done.
Deriving uptime from a PCAP requires knowledge of the access point, its configured protocols, and (in more complex deployments) the coverage strategy of the access point controller. A few minutes of no traffic may not imply that the access point is restarting, or it may, it all depends upon the details.
Moreover with radio systems a lack of traffic may indicate a failure to receive by the monitoring platform, not necessarily a failure to transmit by the access point. Someone may have been microwaving their lunch :-)
Using SNMP is a more typical approach to collecting device uptime. Device uptime can be retrieved using the SNMP variable sysUpTime. That has SNMP object ID iso(1).identified-organization(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysUpTime(3). It is a key variable and implemented on all platforms which claim SNMP compliance.
Edit
The poster of the question has clarified their question
Within the 802.11 hardware is a 1MHz clock maintained in a 64-bit register. That register is initialised to zero when power is applied. Therefore the value of that clock's register is initially the uptime of the WLAN controller in microseconds.
When a Beacon frame or Probe Response frame is transmitted then the value of that clock's register is placed in the Timestamp field.
For a WLAN with a single access point your "aircrack-ng" program can print the Beacon frame's Timestamp field and claim the value is the uptime of the access point.
However, in a multiple access point system the highest value of the Timestamp in all the Beacons received by an access point is written back into that access point's 1MHz clock register. Using this technique all the access points converge on a common value of the 1MHz clock (well, within 25µs or so).
In the multiple access point case we can only say that an individual access point's Beacon Timestamp is the upper bound of the access point's uptime -- the actual uptime of any particular access point could be lower. In fact it's simple to imagine a scenario where there is no access point which has the uptime claimed by the Timestamp.
For more information Google "802.11 Timestamp Synchronization Function", which is the name of the algorithm I have outlined above. You can download the 802.11 specification for free from the IEEE website. You'll find the TSF explained in depth in that specification. There's a lot more depth, as you can imagine from Adhoc networks which have no access points, multiple-SSID access points, and so on.