Re: Constructing a more precise "Now()" and "DateDiff()"
- From: "Mike Williams" <Mike@xxxxxxxxxxxxxxxxx>
- Date: Thu, 4 May 2006 10:13:51 +0100
"Bob O`Bob" <filterbob@xxxxxxxxxxxxxxx> wrote in message news:Ovl1F2ybGHA.4900@xxxxxxxxxxxxxxxxxxxxxxx
In my immediate project, precision is far more important than
accuracy. What's happening is I'm writing a lot of small files
(email messages) and I want some way of distinguishing them
in sequence.
As Jerry has already said, perhaps you might consider simply using your own sequence number. However, if you actually do want to use a "timestamp" and if the resolution of my own suggested method of using GetLocalTime is not sufficient for you then why not just record the actual time (using GetLocalTime or GetSystemTime, whichever best suits your purpose) at the start of your program. At the same time you should record the value returned by the timeGetTime function. Then every time you want to know the current time you simply use the timeGetTime function and deduct from its returned value the initial value that you got from timeGetTime at the start of your program. That will give you a specific number of milliseconds to add to the initially recorded time stamp. Writing a function to do that in a properly formatted way should be very easy. The resolution of timeGetTime is one millisecond (provided you use the timeBeginPeriod API to set the resolution to one millisecond at the start of your program). The only "catch" you would have to watch out for is that the value returned by timeGetTime will wrap if your machine has been permanently on for about 49 days, and will begin to "go negative" as far as VB is concerned after about 24 days, but if that might be a problem for you it is of course very easy to code around.
Otherwise, if the one millisecond resolution of timeGetTime is still not sufficient for your purposes you can instead use QueryPerformanceCounter (in association with QueryPerformanceFrequency) in a similar way. The resolution of QueryPerformanceCounter is machine dependent, but it is always very high and you can virtually guarantee meaningful results for resolutions of the order of about a hundredth of a millisecond. There is a little very rare "glitch" problem with QueryPerformanceCounter (which I think other people have mentioned) but for your specific purposes you won't need to worry about it. You'd have to check that QueryPerformanceCounter was actually available on whatever machine your code is running on of course, but you can do that simnply by calling it and testing for a zero result. Having said that, I don't think there can be many machines about these days on which QueryPerformanceCounter will not work.
Mike
--
.
- Follow-Ups:
- Re: Constructing a more precise "Now()" and "DateDiff()"
- From: Bob O`Bob
- Re: Constructing a more precise "Now()" and "DateDiff()"
- References:
- Constructing a more precise "Now()" and "DateDiff()"
- From: Bob O`Bob
- Re: Constructing a more precise "Now()" and "DateDiff()"
- From: MikeD
- Re: Constructing a more precise "Now()" and "DateDiff()"
- From: Bob O`Bob
- Constructing a more precise "Now()" and "DateDiff()"
- Prev by Date: Re: compare tiff and corresponding image of doc file
- Next by Date: Clear Array Question
- Previous by thread: Re: Constructing a more precise "Now()" and "DateDiff()"
- Next by thread: Re: Constructing a more precise "Now()" and "DateDiff()"
- Index(es):
Relevant Pages
|
