Daylight Saving Time and Your Data Logger

by Janet Albers | Updated: 02/27/2019 | Comments: 10

Tags

LoggerNet

Search the Blog


Subscribe to the Blog

Get an email when a new article is posted. Choose the topics that interest you most.


Area / Application

Product Category

Activity

Corporate / News

Enter your email address:



Suggest an Article

Is there a topic you would like to learn more about? Let us know.

Leave this field empty

Do you need to do anything to your data logger or software to compensate for the beginning of daylight saving time? Read this short article to find out!

moving the clock back an hour for daylight saving time

Residents of many parts of North America, and various areas around the world, continue to observe the practice of daylight saving time (DST) during part of the year by moving their clocks forward one hour in the spring and backward one hour in the fall. Not all areas of the world that follow DST, however, use the same dates for the time changes. For example, for many parts of the U.S., you will move your clocks forward on March 10th this year, whereas many other countries will move their clocks forward on March 31st.

As confusing as all that may be, sorting out your data logger isn’t that tricky. For data consistency, many data loggers are left on standard time throughout the year. To make sure that happens, there are some things you’ll want to take a look at, and understand, in your LoggerNet software settings.

  1. In the Setup Screen, select your data logger from the Entire Network list on the left.
  2. At the top of the screen, select the Clock tab.

On the Clock tab, my checkbox for enabling the Automated Clock Check feature is NOT selected.

Automated Clock Check checkbox is not selected

This means that the feature is disabled, which is what I generally recommend. When this feature is enabled, the data logger clock is compared with the LoggerNet server clock. If the data logger clock is off by at least the amount indicated in the Allowed Clock Deviation field, the data logger clock is automatically reset to match the LoggerNet server clock. Your data logger will not be contacted specifically for a clock check, but, during the next data collection attempt—whether manual or scheduled—the data logger clock will be checked.

Tip: If you live in an area that observes daylight saving time and you set your data logger clock forward an hour, you will get what appears to be a skipped record—because you caused it to be missed.

Future Tip: If you set your data logger clock backward an hour in the fall, when daylight saving time ends, you can end up with two records with the same time stamp. Keep this in mind as you review your data.

Bonus Tip: You can configure LoggerNet so that its time does not correct for daylight saving time. To do this, follow these steps:

  1. In the Setup Screen, select the Tools menu option.
  2. Select LoggerNet Settings.
  3. Click the radio button for Use local time without correction for daylight saving time.
  4. Click the Apply button.

LoggerNet clock setting

I hope this information helps you maintain consistency for your data—no matter what time of year it is or where you live. If you have any questions, feel free to post them below.


Share This Article


About the Author

janet albers Janet Albers was a Senior Technical Writer. She enjoyed sharing tips, simplifying concepts, and guiding our clients to a successful project. She had been with Campbell Scientific, Inc. longer than the CR1000, but not quite as long as the CR10X. After work hours, Janet enjoyed the outdoors with her boys and dogs.

View all articles by this author.


Comments

Peter Wilde | 10/21/2015 at 01:30 PM

At ADH Environmental, where I work, any time-based recording device is always set to local standard time - even during periods of DST. While this can be confusing to uniformed field personnel, it avoids the problem of time change.

jtrauntvein | 10/21/2015 at 02:55 PM

You should be aware that there is a means of configuring LoggerNet so that its times do not correct for DST.  Choose the Setup Screen's Tools/LoggerNet Server Settings menu option, select the radio button that states "Use local time without correction for daylight savings time", and click the Apply button. 

jra | 10/22/2015 at 07:22 AM

Thanks Peter - it's good to hear about experiences from the field.
jtrauntvein - thanks for contributing that additional tip.

jra | 03/10/2016 at 07:19 AM

jtrauntvein - I've updated this article to include your Bonus Tip. 

Happy spring!

djtire | 03/10/2016 at 09:45 AM

It was not clear if there how one could have the "Automated Clock Check" enabled  so that a network of loggers can have their clocks synced continously, but still remain on Standard Time even when the server time has changed to DST. Could you add some detail for those who might want to do this. 

Ken Shackel | 08/26/2017 at 05:22 PM

I collect data remotely (but manually) periodically from a CR3000 using loggernet, and have assumed, maybe wrongly, that the date/time stamp on the data would always be the same as the logger (=station?) clock setting – like it used to be using PC208W and other earlier incarnations of computer/logger software, although in those days you needed to output the date/time as part of the program and you don’t with the CR3000, so I guess things have changed.  In any case, I checked my loggenet server settings and they are set to use local daylight savings time, however, when I look at data from times which should show a shift (e.g., March 12, 2017), there is no jump in the hour at any time, for instance for daylight savings, the time stamp should have gone from 3/12/2017  1:50:00 AM to 3/12/2017  3:00:00 AM, but it went to 3/12/2017 2:00.  Same thing in the fall, so I have 2 questions: 1) does the clock setting on the datalogger have any influence at all on the time stamp in the data, and 2) if the collected data do not show any jumps in the spring and the fall, then does that mean daylight savings time is not being used?  Thanks.

jra | 08/28/2017 at 09:04 AM

Mr. Shackel, 

1) The timestamp in your data is just as you've assumed; it is the time of the station, the CR3000.
2) If the collected data timestamps do not jump it means that the time set in the CR3000 has not been changed. If it was set to daylight saving time, it stayed at dst. If it was set to standard time, it stayed at standard time.

The datalogger clock will not change unless something changes it. The most common ways to change the clock include:
* Manually from the LoggerNet Connect screen, or from the keypad, or other,
* Automatically by LoggerNet when "Automated Clock Check" is enabled as shown above, or
* Instructions in your program.

I hope that helps. Let us know if you have other questions.

Mazhar | 01/30/2019 at 10:04 PM

Dear Janet, I am looking for easy and light means to get a GPS time update. The use is for AWS isolated with very difficult communication. Of course GPS 16X supplied by CS is a very good solution. Nevetheless I am looking for alternative solution like Bad Elf GPS for Lightning Connector https://bad-elf.com/pages/be-gps-1008-detail or other. This product is connected on USB port, so there no way to get time from it on a CR1000X.

If you have experienced other tracks I will be glad to hear from you.

Thank you for your help

Mazhar MERALLI BALLOU

STRATAGEM974

jra | 01/31/2019 at 08:31 AM

Mazhar,

Thank you for your question. Campbell Scientific data loggers have interfaced with many different GPS units. To provide you with the best technical support, please visit https://www.campbellsci.com/contact#dir to find your local Campbell Scientific office.

tjwilli_58 | 10/20/2023 at 07:11 PM

Hi Janet,

I currently have my LoggerNet set to using local time without DST adjustment as in the Bonus Tip. (Thanks jtrauntvein!) So all of my data is in EST year-round. What I'd like to change is to use UTC/GMT time for the timestamp, and add a column for local time (with DST changes) using the DaylightSavingUS(-1) instruction.

Is there an easy way to do that? Maybe use the RealTIme() instuctuction and add an hour depending on the result of DaylightSavingUS() ?

Maybe TableName.TimeStamp?

Please log in or register to comment.