Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

MSDN help for GetThreadTimes & the

Status
Not open for further replies.

PROPAR

Programmer
Oct 25, 2001
51
FR
MSDN help for GetThreadTimes & the FILETIME structures points the fact that :

"Thread creation and exit times are points in time expressed as the amount of time that has elapsed since midnight on January 1, 1601 at Greenwich, England. "

So, why is the reference point of thread timing set to pre-industrial Elizabetan (and Shakespearian) England and not to post Beatles-ian Britain as january 1970 like all other time references ?
 
I think this must be some of the answer. But, it is a guess:

1. ctime is the number of seconds elapsed since midnight (00:00:00), January 1, 1970, coordinated universal time (UTC), and has a resolution of seconds, which is not precise enough when dealing with thread times. FILETIME has a resolution of milliseconds.

2. ctime is a 32 bit integer, which goes from 7FFFFFFF to 80000000 somewhere in 2038, giving applications which have defined it as a signed integer trouble. Not dealing with this now, is making then same mistake as in the 60's and 70's, when dates were stored as 6-digit numbers instead of 8-digit. This was the cause of the Y2K problem.
 
Well my question was more about choosing to zero the FILETIME structure so far away in the past.
FILETIME stores the thread timing in 100-nanosecond time units.
(400 years * 86400 * 365) / 100 x 10E-9 = 1.26144E+17 ticks in the 64 bits FILETIME structure.
This thread count space is forever wasted since no thread will ever give a value of creation or exit times BELOW this value.
Why didn't set the zero value of this count to Jan 01 1970 ?
However, 64 bits gives us a time span of 2^64 100-nanosecond time units, i.e. roughly 58000 years, so the waste is of no great importance.
 
I don't know for sure, but one possible answer for why Jan 01, 1601 was chosen as the zero time is because the Gregorian Calendar was officially adopted in 1582, and therefore, Jan 1, 1601 is the first day of the first full century of that calendar. That coupled with the fact that the Gregorian Calendar is based on a 400 year cycle, means that the years, 1601, 2001 (the start of the millenium), 2401, etc are the cycle restart points for the full calendar. So if you assume that you want the calendar cycle to coincide with the start of the millenium - correctly Jan 1, 2001, then 1 full cycle before that would be Jan 1, 1601.

Again, I am not sure of this, but it at least sounds good. :-D Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top