In log files written by Ultrasonic Personal Air Samplers (UPAS), you'll find each timestamp recorded two different ways: (1) in Coordinated Universal Time (UTC) and (2) in the presumed local time in the sample location (more on that "presumed" part later...).
In the SAMPLE SUMMARY section of the log file header, you'll find the following timestamps:
StartDateTimeUTC and StartDateTimeLocal are really the same time, just displayed in different time zones. The same is true of EndDateTimeUTC and EndDateTimeLocal.
In the SAMPLE LOG, you'll also find the timestamp for each line of data displayed in both Coordinated Universal Time (DateTimeUTC) and the local time zone (DateTimeLocal).
Additionally, in the SETUP SUMMARY section of the log file header, you'll find the GPSUTCOffset parameter, which indicates the difference, in hours, between the UTC and local timestamps recorded in the log file. For example, if the GPSUTCOffset is -7.00, then local timestamps will be seven hours behind UTC timestamps. In this case, a UTC time of 2024-07-11T18:02:30 will correspond to a local time of 2024-07-11T11:02:30.
The UPAS operates and logs data in UTC. When the UPAS is first built, it doesn't know what time it is. During manufacturing, we take the UPAS outside so the integrated GPS module can get the time from GPS satellites. After that, a real-time clock inside the UPAS keeps track of Coordinated Universal Time.
If the UPAS is stored for a while with a dead battery, the real-time clock inside the UPAS can lose power and then the UPAS will lose track of the time. The UPAS won't operate if it doesn't know the time. If you turn your UPAS on to find that the button LED is blinking pink and you can't connect to the app over Bluetooth, that's because the UPAS doesn't know the time. You'll need to take the UPAS outside for a few minutes, to a location where it has an unobstructed view of the sky, so that the UPAS can communicate with GPS satellites to get the time. Clouds won't affect your ability to get GPS signal, but lots of trees and tall buildings might. It should only take a few minutes for the UPAS to get the time and the LED to turn solid pink. If the LED is still blinking pink after 15 minutes, try moving to a location further away from tall buildings.
The UPAS assumes that the local time zone is the same as the time zone on the mobile device used to program the sample. All local timestamps in the UPAS log file are really the UTC time displayed in the time zone associated with the device used for programming.
There are some scenarios in which the local timestamps written to the log file might not reflect the actual local time where the sample was collected:
If you find yourself in one of these scenarios, have no fear. The UTC timestamps in your log file are still correct and will always be correct! Coordinated Universal Time remains the same no matter where in the world you travel and whether or not daylight saving time is in effect in any particular location. That's why researchers who collect time-resolved data in a lot of different locations often prefer to work in UTC instead of local time. Additionally, you can display Coordinated Universal Times in any time zone you prefer when post-processing your data.
In the R programming environment, times are stored using the POSIXct class. The POSIXct class and lubridate package make it easy to keep track of timestamps and display them in different time zones.
When you read log files into R using the read_ast_header() and read_ast_log() functions in our astr package, all UTC and local timestamps will be converted to POSIXct objects in the resulting data frame(s). UTC timestamps from the log file will be displayed in Coordinated Universal Time.
If you do not specify the optional tz argument when calling the read_ast_header() and read_ast_log() functions, all local timestamps from the log file will be displayed in the time zone associated with the GPSUTCOffset from the file header. If you want local timestamps to be displayed in a different time zone, pass the name of that time zone to the optional tz argument.
Here's a real-world example in which the local timestamps in a set of UPAS log files were "wrong" and I specified the optional tz argument in the read_ast_header() and read_ast_log() functions to display local timestamps in the correct time zone: For a recent field campaign, I programmed UPAS in Colorado (UTC-06:00 during daylight saving time) to "always start on next power-on." Then, I shipped those UPAS to California (UTC-07:00 during daylight saving time), where study participants turned them on and collected particulate matter samples. Because I programmed the UPAS in Colorado, using my mobile phone that was set to Mountain Daylight Time, the GPSUTCOffset in each log file was -6.00; however, the UTC offset in actual sampling location was -7:00. When I read these log files into R, I specified the tz argument in the read_ast_header() and read_ast_log() functions as tz = "America/Los_Angeles" so that local timestamps would be displayed in the correct time zone.
Finally, it's helpful to consider the following:
In general, we recommend working in Coordinated Universal Time (like the UPAS does). UTC timestamps recorded by the UPAS will always be correct and you can use the with_tz() function from the R package lubridate to display UTC timestamps in any other time zone.
You can install the astr package from GitHub! This package makes it easier to work with log files recorded by Access Sensor Technologies air samplers in the R programming environment. The astr package can read log files written by UPAS v2.0 (running firmware version ≥ 100), UPAS v2.1, UPAS v2.1 PLUS, and Home Health Box v2.