Click here to Skip to main content
Click here to Skip to main content

Daytime, Internet Time Service Class

, 27 Jan 2004
Rate this:
Please Sign up or sign in to vote.
Methods for updating the system time based on an Internet reference.

Sample Image - InternetTime.jpg

Introduction

Windows XP can automatically synchronize its system clock with an external Internet reference provided by the government. This class provides the same feature under programmer control. You use the Daytime class to get the external date and time, compare it with the current system time, and optionally update the system time.

Background

RFC867, written by Jonathan Postel in May 1983, describes the Daytime protocol, a simple ASCII string which time servers listening on port 13 use to communicate the current time to requestors. The protocol couldn't be simpler: Once a connection is made with the time server, it responds by sending the formatted time string and terminating the connection.

The format of the string is set by NIST, not RFC867. The string looks like:

        JJJJJ YY-MM-DD HH:MM:SS aa b c ddd.d UTC(NIST) *

In addition to the basic month, day, year, hour, minute, second time, the time server also returns a Modified Julian Date (JJJJJ), an indication of daylight savings time status in the United States (aa, "50" if daylight savings), a flag (b, "1" if leap second) indicating that a leap second will be added at the end of the current month, and other data (c is "0" if the time server is functioning normally, ddd.d is the network latency in milliseconds).

The National Institute of Standards and Technology (NIST) maintains several time servers which support Daytime and other standards, such as the Network Time Protocol (RFC1305).

Windows Internet Time Support

Modern Windows systems have support for Internet Time Services (ITS) built-in. The screen shot (above) illustrates the third tab of the system clock's applet. If enabled, Windows will synchronize the clock monthly or on demand.

Using the code

There is no reason to instantiate Daytime objects. The Daytime class wraps four shared methods:

  • Daytime.GetTime() As DateTime - Returns the current UTC time from NIST
  • Daytime.SecondsDifference(dt1 as DateTime, dt2 as DateTime) As Integer - Returns the difference between two times in seconds
  • Daytime.WindowsClockIncorrect() As Boolean - Returns True if NIST time is not close to system time
  • Daytime.SetWindowsClock(utcTime as DateTime) - Sets the Windows system time to utcTime, expressed in UTC.

A call to WindowsClockIncorrect checks the NIST server (trying each server it knows of until it receives a response) and compares it to the current system time. (Note that system time is kept in Coordinated Universal Time (UTC), also known as Greenwich Mean Time (GMT) or, in the military, Zulu. Windows converts UTC to local time using your specified time zone.)

After a call to WindowsClockIncorrect or GetTime, Daytime's two shared variables are updated:

  • Daytime.LastHost As String - The IP address used to get NIST time (or "" if no server responded)
  • Daytime.LastSysTime As DateTime - The Windows system time just before the call to the NIST server, for comparison.

The following code illustrates a typical use of the Daytime class:

    If Daytime.WindowsClockIncorrect() Then
        Daytime.SetWindowsClock(Daytime.GetTime())
    End If

GetTime returns the current system time if it fails to connect with a time server.

Looking at the code itself, you may want to modify the list of time servers or the number of seconds that you'll tolerate between NIST time and the Windows clock. The tolerance, THRESHOLD_SECONDS, is 15 by default. It should be no less than 3 seconds, to account for network delays and general entropy, or you might want to make it zero to force an update every time.

The list of servers comes from NIST Internet Time Servers. As they suggest, the code uses IP addresses instead of host names.

Your results may vary, but here's how the various time servers responded to my computer in San Jose, CA:

53032 04-01-28 19:16:20 00 0 0 320.7 UTC(NIST) *  [129.6.15.28] Gaithersburg, MD
53032 04-01-28 19:16:21 00 0 0 917.8 UTC(NIST) *  [129.6.15.29] Gaithersburg, MD
53032 04-01-28 19:16:21 00 0 0 624.7 UTC(NIST) *  [132.163.4.101] Boulder, CO
53032 04-01-28 19:16:21 00 0 0 406.8 UTC(NIST) *  [132.163.4.102] Boulder, CO
53032 04-01-28 19:16:21 00 0 0 121.3 UTC(NIST) *  [132.163.4.103] Boulder, CO
53032 04-01-28 19:16:22 00 0 0 754.1 UTC(NIST) *  [128.138.140.44] Boulder, CO
53032 04-01-28 19:16:26 00 0 0 124.0 UTC(NIST) *  [192.43.244.18] Boulder, CO
53032 04-01-28 19:16:27 00 0 0 459.2 UTC(NIST) *  [131.107.1.10] Redmond, WA
53032 04-01-28 19:16:28 00 0 0  82.4 UTC(NIST) *  [66.243.43.21] San Jose, CA
53032 04-01-28 19:16:40 00 0 0 110.5 UTC(NIST) *  [216.200.93.8] (Abovenet) VA
53032 04-01-28 19:16:42 00 0 0 657.3 UTC(NIST) *  [208.184.49.9] San Jose, CA
53032 04-01-28 19:16:43 00 0 0 649.7 UTC(NIST) *  [207.126.98.204] Sunnyvale, CA
53032 04-01-28 19:18:03 00 0 0 441.7 UTC(NIST) *  [205.188.185.33] (AOL) VA

Owing to the MyDoom virus, perhaps, you can see that this test took 163 seconds to complete. Because the first server will likely respond successfully, performance is usually sub-second, but I wouldn't try doing it in a tight loop.

Future Enhancements

It might be nice in the future to test the Internet connection before calling a time server. I assume that dialup users would not want to routinely dial up just to adjust their clock. Fortunately, code to check LAN, DIALUP, or OFFLINE is fairly simple; it is described in Microsoft Knowledgebase Article 821770.

Another possible enhancement would be to call several time servers and average their times, as is typical in Network Time Protocol (RFC1305) implementations.

Points of Interest

This code illustrates a simple TcpClient session and a simple call to the Windows Kernel DLL.

The NIST time string has only a two-digit year. (Remember the Y2K problem that was going to freeze elevators and have airplanes fall from the sky?) We have to look at the Modified Julian Date (MJD) to be sure that '04' means 2004. The code, as written, can handle NIST dates in the 1900s (MJD 15020 to 51543) or the 2000s (MJD >= 51544), but of course this code should never see a date earlier than 2004.

History

01/27/2004 AD: Initial

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

Share

About the Author

Alastair Dallas
Web Developer
United States United States
Alastair Dallas is a programmer, systems architect, and information designer with over 20 years experience at companies including Ashton-Tate, Lotus, Netscape, Documentum, and a wide variety of startups. Languages include C#, C, C++, Java, JavaScript, Perl, Python, and VB (in alphabetical order) as well as DHTML, XML, and related technologies. He has written 3 books, 2 on computer topics, and is President of Infospect Press.

Comments and Discussions

 
GeneralHelp PinmemberDermot French8-Oct-07 10:20 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.1411023.1 | Last Updated 28 Jan 2004
Article Copyright 2004 by Alastair Dallas
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid