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?
-
You statement "how to calculate what the Epoch will be in the future, say for example 10 minutes from now" is confusing. The Unix Epoch is always 01/01/1970 00:00:00, even in 10 minutes time! Do you mean "how to calculate the number of seconds since Unix Epoch will be in the future, say for example 10 minutes from now" – Chris Walsh Mar 23 '16 at 09:52
4 Answers
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 25 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 about the real number of seconds passed since the Unix epoch, you should probably add the leap seconds to the result obtained above for applications that rely on this. You would have to track the number of seconds to add at each time since leap seconds are not announced far in advance (2). However, as the definition of Unix Epoch Time explicitly excludes leap seconds, you can safely ignore this and simply recalculate seconds from the current UTC time.
Sometimes, leap seconds do cause software mayhem (5). The debate over whether to keep or eliminate the practice is ongoing (6)(7)(8).
The last leap second at the time of the answer occurred on the 1st of July 2012 (9) and caused problems for various sites and applications (10)
(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/
(7) http://queue.acm.org/detail.cfm?id=1967009
(8) http://arxiv.org/abs/1106.3141
(9) http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
(10) http://arstechnica.com/business/2012/07/one-day-later-the-leap-second-v-the-internet-scorecard/
(The original answer had a mistake, which was thankfully caught by the commenters Edward Brey and Mormegil below)

- 1,945
- 2
- 19
- 18
-
1+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 May 25 '09 at 11:47
-
3I don’t _think_ this is correct. Both assumptions are fine (Unix and Windows both do not count/know leap seconds), but you make the wrong conclusion, IMHO. Unix time ignores leap seconds, which means it thinks `1973-01-01T00:00:00Z` is Unix time 94694400, i.e. `(365 + 366 + 365) * 24 * 60 * 60`, even though two leap seconds elapsed in the meantime. And exactly the same thing is true for Windows. It knows from the NTP master it is `1973-01-01T00:00:00Z`, but it does not know about two leap seconds. Unix&Windows time are not continuous time scale, but they are in sync with each other. – Mormegil Feb 21 '14 at 21:39
-
This is why iI said 'pedantically correct". We compare against the official definition of Unix Epoch time, not against the practical implementation on a Unix system, which as you point out is in the same boat as Windows. – Peter Stuer Jul 01 '15 at 06:07
-
2The practical Unix implementation is pedantically correct. Its epoch-based math doesn't account for leap seconds, which matches the official definition. To clarify, here is a pedantic Q&A: What is the Unix Epoch Time for 1973-01-01T00:00:00Z? 94694400. How many real-world seconds elapsed from 1970-01-01T00:00:00Z to 1973-01-01T00:00:00Z? 94694402. – Edward Brey Jul 02 '15 at 11:45
-
Thanks for the clarifications Edward Brey and Mormegil.I will edit the asnwer to reflect your insights. – Peter Stuer Jul 03 '15 at 14:37
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.

- 144,213
- 56
- 264
- 302
-
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 May 25 '09 at 12:35
-
@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 May 25 '09 at 18:40
-
So I finally actually read through your code and understand it. I wish I could up-vote this about 10 more times. Thanks :) – UnkwnTech Apr 08 '10 at 06:32
The basic solution:
- Take Current Time
- Add Offset to Future (10 Mins, in your example)
- Subtract Midnight of Jan 1st 1970
- 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;

- 1,799
- 13
- 13
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);

- 43,500
- 17
- 101
- 157
-
This needs to be done in the UTC time frame, but otherwise is correct. – Noldorin May 25 '09 at 09:35