We Keep Coding

How to ensure timer records at fixed interval?

I'm trying to create a windows phone application that records the accelerometer data at 100 Hz. I tried out both System.Windows.Threading.DispatcherTimer and System.Threading.Timer, but looking at the data recorded, neither were actually recording at 100 Hz. DispatcherTimer records 60-80 Hz, while Timer records at around 85-90 Hz. I don't think the problem is the phone not being able to handle it, since when I tried recording at 50 Hz, it was still lagging to only 40+ Hz. Here is a snippet of my code:
For DispatcherTimer:
timer = new DispatcherTimer();
timer.Interval = TimeSpan.FromMilliseconds(10);
timer.Tick += new EventHandler(timer_Tick);
For Timer:
timer = new Timer(timer_Tick, null, 0, 10);
How do I make sure that I am recording at a fixed rate interval?

Windows Phone 7 - is not a real-time OS. None of the timer classes are exactly precise. All you're doing it saying that you want to wait at least this long. It takes some amount of time for everything to fire and you to end up notified that the timer has ticked once OS gets around to actually servicing the tick message.
Try to implement simple test: Print current time every 10 milliseconds, and you can see minimum error. When developers use 1 or 5 or 10 seconds like interval - this is not noticeable.

How to make precise clock in XNA?

I am making an XNA game and it's time to make daytime system and for that I need some kind of clock. I tried to use GameTime.TotalGameTime.Milliseconds == 0 to add one second to the second counter of my custom clock class, but it turned out that GameTime doesn't always run through zero milliseconds. Using TimeSpan prevUpdate to compare to TotalGameTime.TotalSeconds doesn't give enough precision, and the time is noticeably slower than the real time somehow.
What XNA or .Net component can I use to base my clock on so that it doesn't cost too much resources or deviates noticeably from real time?

Use Stopwatch for high-precision timing (reference).
Use XNA's GameTime for rendering and frame-to-frame timing logic. XNA's timer does not match "wall clock" time exactly. It is able to drift in order to better line up with frame rendering, giving you smoother animation (this is behaviour is provided by the Game class). Over time it will deviate from real time slightly, but for most games this is not a problem.
Use DateTime for measuring longer time spans accurately (eg: minutes, hours).
Note that you shouldn't compare Milliseconds == 0, because you cannot know exactly when XNA will call your Update method, so you could have Milliseconds == 999 on one frame, and then Milliseconds == 15 the next - wrapping around and skipping past 0, so your condition never triggers.
So you need to determine when the timer crosses the threshold. There are many ways to do this. You could track a threshold (useful if you are tracking some "total" time), incrementing it after each trigger. Personally I prefer to accumulate time like so:
seconds += gameTime.ElapsedTime.TotalSeconds;
if(seconds > 1.0)
{
seconds -= 1.0;
DoSomething(); // Triggered each second
}

Timer takes more time

Scenario:
In a Winform application(C#), I have a Datagridview in which I have to display 4 countdown timers in the format "mm:ss".
Time Interval must be 1000ms.
I was counting the timer down in the elapsed event of system.timers.timer.
On all 4 timers I'm starting to countdown from 2 mins (02:00).
Issue:
It takes more time(125 seconds) than 2 mins, to reach 00:00.
Similarly for 4 mins it takes 7-10 more(247 -250) seconds to reach 00:00

Timers on systems are somewhat of an inaccurate beast. Better systems generally provide better timers but even the best system has slippage.
You also need to remember that your process isn't going to be in "full control" 100% of the time, it will at times be pushed into the background and have to share the processor with other applications so whilst it's does its best to keep track of the time.
What you probably want is a High Precision Timer (aka stopwatch) in C#. Have a look at This thread and This article on selecting timer mechanisms for some more information.

If you need time resolution of that type (i.e. actual clock or countdown clock), you should use the real-time clock.
You still use a timer with sub-second resolution to fire frequently enough for display purpose, but you don't add up those times, you use the real-time clock to get the real elapsed time (DateTime.Now - startTime).

First off you should run this little test and see the drift in near real-time. I lose a 1 second after 72 timer elapsed events (this is with very little actual work).
using (var timer = new Timer(1000))
{
var start = DateTime.Now;
var i = 0;
timer.Elapsed += (sender, args) => Console.WriteLine("{0} -> {1}", ++i, (DateTime.Now - start).TotalMilliseconds);
timer.Start();
Thread.Sleep(130*1000);
}
I'm not sure how precise your app needs to be but you can get "good enough" by using the delta between the start time & now and subtracting that from your initial value and killing the timer at zero. You will lose seconds with this approach and there's a reasonable chance that lost second could happen # 0:00 causing a -0:01 tick, which you will need to handle.
var countdownSeconds = 120;
var startedAt = DateTime.Now;
var timer = new Timer(1000);
timer.Elapsed += (sender, args) => Display(countdownSeconds - (int)((DateTime.Now - startedAt).TotalSeconds));
timer.Start();
//- be sure to dispose the timer

Thread sleep/wait until a new day

I'm running a process in a loop which has a limit on the number of operations it does per day. When it reaches this limit I've currently got it checking the the time in a loop to see if it a new date.
Would the best option be to:
Keep checking the time every second for new date
Calculate the number of seconds until midnight and sleep that length of time
Something else?

Don't use Thread.Sleep for this type of thing. Use a Timer and calculate the duration you need to wait.
var now = DateTime.Now;
var tomorrow = now.AddDays(1);
var durationUntilMidnight = tomorrow.Date - now;
var t = new Timer(o=>{/* Do work*/}, null, TimeSpan.Zero, durationUntilMidnight);
Replace the /* Do Work */ delegate with the callback that will resume your work at the specified interval.
Edit: As mentioned in the comments, there are many things that can go wrong if you assume the "elapsed time" an application will wait for is going to match real-world time. For this reason, if timing is important to you, it is better to use smaller polling intervals to find out if the clock has reached the time you want your work to happen at.
Even better would be to use Windows Task Scheduler to run your task at the desired time. This will be much more reliable than trying to implement it yourself in code.

Windows has a task scheduler that handles exactly this duty. Create the program to do that which it is supposed to do. Then set it up as a scheduled task.

Just calculate a period to wait and run an asynchronous timer in this way you can avoid extra CPU consuming whilst waiting:
var nextDateStartDateTime = DateTime.Now.AddDays(1).Subtract(DateTime.Now.TimeOfDay);
double millisecondsToWait = (nextDateStartDateTime - DateTime.Now).TotalMilliseconds;
System.Threading.Timer timer = new Timer(
(o) => { Debug.WriteLine("New day comming on"); },
null,
(uint)millisecondsToWait
0);

Considering the two options you've provided:
There are 60*60*24 = 86,400 seconds per day, so you could potentially do a lot of checking if you hit the limit early. Additionally, busy waiting is a waste of CPU cycles, and it will slow down everything else that is running.
You should calculate the number of seconds until midnight and sleep that long (although I believe the sleep paramater takes ms rather than s, so a simple conversion may be needed).
EDIT:
An additional benefit of calculating then sleeping is that if a user wants to bypass your restriction by changing the clock, they will not be able to (since the clock reading midnight won't wake the process as it would with continual checking). However, with a better understanding of how your program works internally, the user could change the clock to almost midnight every time they are about to reach the limit of operations, causing the thread to wake up in a few minutes or even a few seconds. It's a more complicated exploitation than would be doable with your first suggestion, but it can be done.

This is how I make a thread sleep till tomorrow 6AM
minutesToSleep = (int)(new DateTime(DateTime.Now.AddDays(1).Year, DateTime.Now.AddDays(1).Month, DateTime.Now.AddDays(1).Day, 6, 0, 0) - DateTime.Now).TotalMinutes;
Console.WriteLine("Sleeping for {0} minutes (until tomorrow 6AM)", minutesToSleep);

C# - Time calculation not working with TimeSpan.FromTicks DateTime

I am trying to calculate a video framerate in a program. To do this I take
DateTime.Now
at the beginning of a stream, and then again after every frame whilst also incrementing a framecounter.
Then I calculate the FPS like so:
int fps = (int)(frames / (TimeSpan.FromTicks(CurrentTime.Ticks).Seconds - TimeSpan.FromTicks(StartTime.Ticks).Seconds));
The problem is that I occassionally get a negative number out, meaning the start time must be later than the current time. How can this be the case? Does anyone know anough about these functions to explain?

Seconds gives you the seconds part of the TimeSpan, not the total duration of the TimeSpan converted in seconds. This means that Seconds will never be greater than 60.
Use TotalSeconds instead

You should consider using StopWatch for such needs, It has much better precision

The datetime functions are probably not precise enough for your needs, you may want to look into performance counters instead. I think the StopWatch class is what your looking for. System.Diagnostics.StopWatch. that is using the QueryPerformanceFrequency and QueryPerformanceCounter functions for the timing.