tags:

views:

1942

answers:

4

I was able to find example code to get the current timestamp in Linux Epoch (Seconds since Midnight Jan 1st 1970), however I am having trouble finding an example as to how to calculate what the Epoch will be in the future, say for example 10 minutes from now, so how can I calculate a future time in Linux Epoch?

A: 

The basic solution:

  1. Take Current Time
  2. Add Offset to Future (10 Mins, in your example)
  3. Subtract Midnight of Jan 1st 1970
  4. Get the total number of seconds between the two

In c# (off the top of my head, untested):

DateTime myEpoch = DateTime.Now.Add( new TimeSpan(...) );
return myEpoch.Subtract( new DateTime(1970, 1, 1, 0, 0, 0) ).TotalSeconds;
Nick
+9  A: 

This extension method should do the job:

private static double GetUnixEpoch(this DateTime dateTime)
{
    var unixTime = dateTime.ToUniversalTime() - 
        new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);

    return unixTime.TotalSeconds;
}

And you can use it as such:

var unixTime1 = DateTime.Now.GetUnixEpoch(); // precisely now
var unixTime2 = (DateTime.Now + new TimeSpan(0, 10, 0)).GetUnixEpoch(); // 10 minutes in future

Note that you need to deal with all date-times in UTC (Universal Time), since that's how the start of the Unix Epoch is defined.

Noldorin
Note that ToUniversalTime() treats times with an Unspecified Kind as local, which may or may not be correct for your app. That's why it's always best to specify the Kind when creating a DateTime. See http://msdn.microsoft.com/en-us/library/system.datetime.touniversaltime.aspx
Matthew Flaschen
@Matthew: Yeah, good point (although it's not something to worry about if you're just using times relative to Now). You still need to convert to UTC anyway however.
Noldorin
So I finally actually read through your code and understand it. I wish I could up-vote this about 10 more times. Thanks :)
Unkwntech
+1  A: 

Whats the function you use to get the current time ?

Sure that takes a .NET DateTime parameter...

Surely it's just a simple matter of passing in a future DateTime to the function.

or doing a DateDiff in seconds between the current time and the future time and adding that on.

var dt = new DateTime(1970, 1, 1, 0, 0, 0).ToUniversalTime();

var now = System.DateTime.Now.ToUniversalTime();
var future = new DateTime(2010, 1, 1).ToUniversalTime();

Console.WriteLine((now - dt).TotalSeconds);
Console.WriteLine((future - dt).TotalSeconds);
Eoin Campbell
This needs to be done in the UTC time frame, but otherwise is correct.
Noldorin
Cheers, updated for clarity
Eoin Campbell
+10  A: 

There is an interesting twist when you want to know the Unix Epoch time in .Net on a Windows system.

For nearly all practical cases and assuming the current time is past the Unix Epoch you could indeed take

System.TimeSpan timeDifference = DateTime.UTCNow - 
            new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
long unixEpochTime = System.Convert.ToInt64(timeDifference.TotalSeconds);

But,

Unix Epoch Time is defined as "... a system for describing points in time, defined as the number of seconds elapsed since midnight Coordinated Universal Time (UTC) of January 1, 1970, not counting leap seconds." (1)

Since 1972, UTC has included "leap seconds", and we have had a total of 24 of them so far. (2)

The .Net DateTime has no provisions for Leap Seconds, but will simply rely on the OS time. Windows is blissfully unaware of Leap Seconds (3)(4), and so will just have the notion of time as it receives it from its NTP master (I believe the default for a non-domain connected machine is time.windows.com ), which is probably serving up UTC including leap seconds.

This means that in order to be pedantically correct you should probably add 24 seconds to the result obtained above to obtain the correct Unix Epoch Time right now. You would have to track the number of seconds to add in the future since leap seconds are not announced far in advance (2).

Sometimes, leap seconds do cause software mayhem (5). The debate over whether to keep or eliminate the practice is ongoing (6).

(1) http://en.wikipedia.org/wiki/Unix_time

(2) http://en.wikipedia.org/wiki/Leap_second

(3) http://support.microsoft.com/kb/909614

(4) http://www.meinberg.de/english/info/leap-second.htm

(5) http://www.networkworld.com/news/2009/010609-leap-second-snafu-affects-oracle.html

(6) http://www.pcworld.idg.com.au/article/358024/time_waits_no_one_leap_seconds_may_cut/

Peter Stuer
+1 cause this is interesting, however since I am working on a scale of minutes (more like hours in most cases) and the operations are not super precise, I don't think that 24 seconds is going to be a big problem, but thank you for pointing it out.
Unkwntech