Get Unix Time

[Zssffssz]

I want to get unix time in my program, google just brought up how to get time on a unix system (I'm on a dos/windows system). Is there an easy (can fit in less than 20 lines of non-system dependent functions and without any API or WIN32 [unless simple] functions) way to do this?
I am very aware about the January 19 2038 problem.
I have seen time_t but don't know how to use it at all (or for this).

[L7Sqr]

If you are on a Windows box then UNIX time is pretty useless, yes?
Maybe you want something like 'seconds since the epoch' or similar to that?

[chary8088]

the API of getting time are the same on Windows and *nix(UNIX, linux);
following codes should meet your requirement

char lstime[128] = "";

struct tm *lptr = localtime(&time(NULL));
strftime(lstime, sizeof(lstime), "%Y-%m-%d %H:%M:%S", lptr);
cout<<lstime<<endl;

[Zssffssz]

Two things:
One, Unix time sounds cool, answer to first post.
Two, Sorry dude but could you explain some of that, I trust that that's quality code but I like to know what I'm using and how it works.

[chary8088]

your questions can be easy got answers by google or look up in related books.
why not do by yourself?

don't be lazy..

[Zssffssz]

Like I said I searched but it was all for unix systems...

[WaltP]

Maybe you need to clarify what you mean by Unix Time. AFAIK, time is time. What are the differences you know that we don't?

[Zssffssz]

According to Wikipedia: Unix Time is a time measurement that ignores leap seconds. It is measured by the number of seconds since January 1, 1970.
Which I think is the Epoch.
It is normally assoseated with time_t which is defined as signed int (which is causing the 2038 problem). Umm...
I pretty sure this is it.

[WaltP]

Seriously, what is the difference between calling time() on Unix vs Windows? What is it you are really looking for?

[Zssffssz]

I didn't know that there was a time function...
Thanks

[WaltP]

Really...

See above:
http://www.daniweb.com/software-development/cpp/threads/394459/1693752#post1693752

[vijayan121]

> Seriously, what is the difference between calling time() on Unix vs Windows?

Seriously? It depends. Entirely on the C library implementation that is being used.

POSIX requires that time() returns a 32-bit integral type holding the number of seconds elapsed since midnight (UTC) of January 1, 1970, not counting leap seconds since 1970. C/C++ implementations on Unix adhere to the POSIX specification.

On a non-posix system, using an implementation where the particular compiler vendor does not guarantee POSIX conformance, things are far more nebulous. The C standard itself doesn't specify anything more than time_t being an arithmetic type capable of representing calendar time. It doesn't specify the epoch; or for that matter that there should be an epoch at all or that leap seconds exist. It also doesn't specify the granularity of time_t other than that it is implementation-dependent. On one implementation, time_t could be a signed integral type holding one hundreths of a second since some epoch foo. On another, it might be a double representing seconds, with fractional milliseconds, since some other epoch bar.

Hence, the C standard also has:
double difftime( time_t time1, time_t time0 ) ;
"The difftime() function shall return the difference between two calander time values expressed in seconds as a type double."

And C++ felt the need to add <chrono>.

[mike_2000_17]

To add to vijayan121's great explanation.

Although nice, the <chrono> header doesn't solve the problem of the epoch of reference, it is still implementation-defined, which is a good thing in general, but a problem, of course, if you want some type of absolute reference.

The Boost.Date-Time library is a good place to go for pretty feature-rich facilities to manipulate time, and it does include all the necessary conversions. For instance, you can use the posix-time for any system (the library handles the required epoch and duration conversion if any).

[WaltP]

> Seriously, what is the difference between calling time() on Unix vs Windows?

Seriously? It depends. Entirely on the C library implementation that is being used.

POSIX requires that time() returns a 32-bit integral type holding the number of seconds elapsed since midnight (UTC) of January 1, 1970, not counting leap seconds since 1970. C/C++ implementations on Unix adhere to the POSIX specification.

On a non-posix system, using an implementation where the particular compiler vendor does not guarantee POSIX conformance, things are far more nebulous. The C standard itself doesn't specify anything more than time_t being an arithmetic type capable of representing calendar time. It doesn't specify the epoch; or for that matter that there should be an epoch at all or that leap seconds exist. It also doesn't specify the granularity of time_t other than that it is implementation-dependent. On one implementation, time_t could be a signed integral type holding one hundreths of a second since some epoch foo. On another, it might be a double representing seconds, with fractional milliseconds, since some other epoch bar.

Hence, the C standard also has:
double difftime( time_t time1, time_t time0 ) ;
"The difftime() function shall return the difference between two calander time values expressed in seconds as a type double."

And C++ felt the need to add <chrono>.

All well and good, from the internal development of the compiler. The question is will calling time() on Unix give a different time than on Windows? In other words, would Unix give Mar 10, 2009 10:13AM and Windows give Mar 11, 2009 10:18AM ?

My conclusion is there is no difference from a user standpoint (I believe that's where the OP is concerned) in any compiler written. All will return the same 'time'. Might be a different internal value, but each value will represent the same time.

[vijayan121]

> The question is will calling time() on Unix give a different time than on Windows?
> In other words, would Unix give Mar 10, 2009 10:13AM and Windows give Mar 11, 2009 10:18AM ?

time() is a C function; so what it returns depends on the implementation of the C runtime library. For instance, on Windows the Cygwin library and Microsoft CRT will return completely different values.

The result type of time() is an implementation-defined time_t. In every conforming implementation, time_t holds the representation of an abstract time point (a point in the abstract time continuum defined by the implementation).

Mar 10, 2009 10:13AM etc are wall-clock times specific to a calendar system and a time system. (An approximate mapping between the abstract time point and wall-clock times belonging to two calendar time systems are also part of the standard C library.)

> I want to get unix time in my program....
> Is there an easy (can fit in less than 20 lines of non-system dependent functions
> and without any API or WIN32 [unless simple] functions) way to do this?

IMHO, mike_2000_17's suggestion - use Posix Time from Boost Date_Time library - is by far the best.

If you want to do it yourself, this is the kind of thing that is normally done when a mapping between Windows time and Unix time is required. (The code is based on that from Citrix.)

#include <cstdint>
#include <windows.h>

std::int32_t unix_time()
{
   SYSTEMTIME system_time ;
   GetSystemTime( &system_time ) ;
   FILETIME file_time ;
   SystemTimeToFileTime( &system_time, &file_time ) ;
   // Windows file time: number of 100 nanosecond intervals since January 1, 1601 UTC
   std::int64_t windows_time = file_time.dwHighDateTime << 32U + file_time.dwLowDateTime ;

   // Unix time: number of seconds (excluding leap seconds) since January 1, 1970 UTC
   // There are 134,774 days between these dates
   enum { NDAYS = 134774 } ;
   const  std::int64_t NSECONDS = NDAYS * 24 * 60 * 60 ;
   return ( windows_time / 10000000 ) - NSECONDS ;
}

Assuming that this is used on a Windows machine where the (NT based) kernel is disciplined by ntpd, the difference should never be more than one second (except minimum one, maximum two for about 35 minutes or so following an NTP leapsecond announcement).

[WaltP]

I wasn't asking to get a dissertation on how time() works. (note my post count and Mod status -- I do know something :icon_rolleyes:)
It was to make the OP think about his question.

[vijayan121]

> (note my post count and Mod status -- I do know something )

Your post count is a number that says absolutely nothing about the quality of your posts.

A moderator here performs two roles - that of a policeman and that of a sanitation worker. Your moderator status implies that you are adept at those two tasks. As a member of this community, I'm very grateful to you for that. However, it too says absolutely nothing about the quantum of your knowledge.

A stalwart member of the constabulary, who is also an accomplished janitor to boot, is someone to be admired. Be that as it may, that alone does not make him eminently qualified to teach differential calculus.

> It was to make the OP think about his question.

Ah, I see. The OP wanted a Unix timestamp - an unsigned 32-bit value which held the number of seconds elapsed since midnight UTC, January 1, 1970 (not counting leapseconds). Informing him that this is just what time() returns on any non-posix implementation must be the best way to make him think long and hard.

[mike_2000_17]

Calm down people. Don't antagonize yourselves over such a trivial issue.

@vijayan121: I think all WaltP is saying is that a technically correct answer isn't always the best answer to a question. That doesn't warrant any attacks on his technical knowledge.

@WaltP: You assume that there is no reason whatsoever to want to have time represented as the number of seconds since the unix-epoch, as opposed to just having some representation of time (translatable to calender time). I think that assumption is wrong. I can easily think of a few reasons (some better some not so good) for wanting or needing that.

At this point, I think it's the OP's turn to give his input on what he needs posix-time for (if he stills needs that) and if any of the suggested solutions solve his problem (if not, why?).

[vijayan121]

> a technically correct answer isn't always the best answer to a question.

I realize that a question that is asked is not always the most appropriate one. Though in this case there is no evidence to suggest that that is the case. No matter what, deliberately giving a misleading answer is never right, let alone repeatedly insisting that that wrong answer is the right one.

> That doesn't warrant any attacks on his technical knowledge.

I have been careful throughout not to introduce personal elements into a technical discussion. I wasn't the one who introduced them; and even then I restricted by response to contesting the patently absurd claim that number of posts and being a moderator here is proof of undeniable technical eminence.

You are entitled to your opinions of course, just as much as I am to mine. And in my opinion, it is your presumptuous comment that is completely unwarranted.