New Timestamp and Library API


Related Items: GSoC2013NewTimestampAndAPIKeyParts, GSoC2013NewTimestampAndAPIDesignOfProject, GSoC2013NewTimestampAndAPIWeeklyUpdates, GSoC2013NewTimestampAndAPIDocuments, GSoC2013NewTimestampAndAPITestCases

There are different timescales being used everywhere, like UTC and GPS. When user application gets timestamp from system, it can’t tell which timescale the system is using. What’s more, the timestamp being used may step backward in cases such as system time is set manually, which could be disaster to time-sensitive applications. So this idea aim to design and implement a new timestamp format and API that will never step backward and provide an easy-to-use interface for programs to fetch timestamp and process with it.


As there are many different and widely-used timescales, functions like ‘gettimeofday()’ can no longer satisfy our requirement. It can only tell us the current system time, but can’t tell us what timescale is being used now, and how accurate it is, which is practical for use case e.g. synchronization.

If we can develop a new timestamp system that provides more information about system time, it will bring great convenience.

What’s more, the timestamp system we are using now may step backward, which is a disaster for some time-sensitive applications like database.

Therefore, we aim to implement a new timestamp API which never steps backward. When negative offset is to be applied, our new timestamp API will just write offset to system variable and system kernel will gradually adjust time to the right value in a long period.


  • Design a new timestamp API that support conversion from system timestamp, and fundamental operations include add/subtract/comparison.
  • Implement this new timestamp API in Linux kernel (If time permitted, BSD kernel will be included). Which will provide similar usage like gettimeofday().
  • Fully test the implementation. Write detailed wiki pages and documentations.


Date Task Description % Done
(Period Start)      
05-04 Preparation Work Read documents and codes related to this project, prepare for programming enviroment. choice-yes
05-28 Determind the design Discuss with mentor about the design and make determination about some of them. choice-yes
06-02 Coding Begins Implement the "GetNewTimestamp()" and "ConvertTimestamp()" function.
At least support the conversion between UTC timescale, GPS timescale and TAI timescale.
06-17 #Exam Period# This period will be mainly used for preparation for exams.
Test the work that has been done before this period, and k eep contact with mentor about the design and implementation.
07-01 Boot Counter and Offset Design and implement boot counter (may not needed now) and expected offset module, along with "SetOffset()" function.
Write a tiny program to simulate the process of applying offset to system clock smoothly.
07-15 Expected Error
Design and implement the “expected error” module, including the mechanism that make error values accumulate over time.
Design and implement the arithmetic and comparison function on timestamp .
07-29 BO Midterm Evals Mentors and students can begin submitting mid-term evaluations. choice-yes
07-30 Put together Put all parts together, and make them work well.
If the implement work all going well, this period will also be used to port my work to other platforms like BSD.
08-02 EO Midterm Evals Mid-term evaluations deadline. choice-yes
08-12 Testing and Bug Fixing Most time of this period will be used in rigorous testing, bug fixing and generating test cases.
Begin writing documentations and corresponding wiki pages.
08-26 Complete documentations Finish writing documentations and wiki pages. choice-yes
09-02 Buffer Time A buffer of two weeks kept for any unpredictable delay. choice-yes
09-16 Wrap-up Suggested "Pencils Down" date. Take a week to scrub code, write tests, improve documentation, etc. choice-yes
09-23 Firm "Pencils Down" Mentors, students and organization administrators can begin submitting final evaluations to Google.  
09-27 Final Evaluation Final Evaluations Deadline  
09-27 Code Samples Students begin uploading code samples  
10-01 Final Results Final Results Announced  

Discussion and Comments

  • Instead of a "boot counter" we may want a "clock discontinuty counter", as that's the real purpose behind the "boot counter" idea. Zefram suggested some other ideas too, and we should decide if they should be incorporated now or later. Specifically, he thinks we might want some of the error/uncertainty values to be a custom floating-point value, using 8 bits of exponent and 8 bits of significand. At least the significand can be unsigned. These values can be easily converted to a float. He also points out that some clock sources will not need an "expected offset to correct time". -- HarlanStenn - 20 Jun 2013
Topic revision: r21 - 29 Jan 2015, SueGraves
No permission to view System.WebTopBar
No permission to view System.WebBottomBarExample