0

I am getting the "LastWriteTime" of my executable and comparing it to an internal DateTime that I have set. If the LastWriteTime is less than or equal to the internal DateTime then I will clear two tables from a database.

This code works great for me in the Pacific Time Zone. But if a user is in another time zone, (example 4 hours ahead of me), then it does not work because the "LastWriteTime" returns the time converted to their time zone. For example, I am looking for the value of "12/12/2012 8:38:12 AM" and if they are 4 hours ahead of me, this value gets automatically changed to "12/12/2012 12:38:12 PM" on their systems.

Can someone please show me what I should modify in my code to take into account for different time zones so the "LastWriteTime" and my 'build2023_EXE_Date' variable both return the same Date/Time so my comparision of the two date/time values don't fail regardless of what time zone my end user is in?

I am using .NET 3.5, not .Net 4.x

//http://stackoverflow.com/questions/1600962/displaying-the-build-date
string w_file = "MyEXE.exe";
string w_directory = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) +
                       Path.DirectorySeparatorChar + "MyEXE";

DateTime currentExeTime = File.GetLastWriteTime(System.IO.Path.Combine(w_directory, w_file));


DateTime build2023_EXE_Date = new DateTime(2012, 12, 12, 8, 38, 12); //"12/12/2012 8:38:12 AM"

//We need to truncate the millisecond time off of the EXE LastWriteTime
//or else when we compare to our internal DateTime build2323_EXE_Date value,
//it will not match
//http://stackoverflow.com/questions/1004698/how-to-truncate-milliseconds-off-of-a-net-datetime
currentExeTime = new DateTime(
     currentExeTime.Ticks - (currentExeTime.Ticks % TimeSpan.TicksPerSecond),
            currentExeTime.Kind
            );

if (currentExeTime <= build2023_EXE_Date) //If previous build matches or is before the Build 2023 date then clear these two tables.
{
    //This will fail the comparision if the user is in a different time zone than me.
    //Clear tables
}
fraXis
  • 3,141
  • 8
  • 44
  • 53

2 Answers2

4

Unless you've got a specific need to keep dates in local time or have an associated time zone, I suggest you use universal time instead. This makes working with dates far easier because they all compare sanely, and it can actually be more performant (when you request DateTime.Now, .NET calls DateTime.UtcNow and then performs a relatively expensive adjustment to local time).

Another option is to use DateTimeOffset, which stores a date with an offset (not a time zone! -- for instance, DST will give you different offsets) and makes comparisons as easy as a universal DateTime. Unfortunately, though, GetLastWriteTime doesn't use DateTimeOffset so this might not work for you.

Cory Nelson
  • 29,236
  • 5
  • 72
  • 110
  • I don't have a specific need to keep the dates in any particular time zone. I just want to make sure both dates when I compare them are translated to the same time zone when I do the comparison. – fraXis Dec 21 '12 at 17:48
  • Would using this work for me? "if (c3.ToUniversalTime() <= build2023_EXE_Date.ToUniversalTime())" Would that cause the comparison to always pass if the criteria is met regardless of a user's timezone? – fraXis Dec 21 '12 at 18:04
  • keep the date in the database as a universal time, and have the clients send their time in universal time (only the client knows what time zone they are in, so you can't convert it on the server) – Cory Nelson Dec 21 '12 at 18:38
1

Use the DateTime ToUniversalTime() method

VladL
  • 12,769
  • 10
  • 63
  • 83
  • Would I just make my comparison look like this? if (c3.ToUniversalTime() <= build2023_EXE_Date.ToUniversalTime()) – fraXis Dec 21 '12 at 18:03
  • In case of build2023_EXE_Date there is no information about timezone, so either set it or just compare build2023_EXE_Date and c3.ToUniversalTime() if you are sure, that build2023_EXE_Date is UTC – VladL Dec 21 '12 at 19:33