Hello...

    I am having some difficulty coming to terms with how C/C++ handles time.
In the client/server application that I am writing, the client and server
will periodically exchange information dealing with times and dates -- so I
want to make sure that I am interpreting the Visual C++ documentation
correctly.

    1) As I understand it, time_t stores the  number of seconds passed since
midnight, Jan 1, 1970 GMT. So, if the client and server are in different
time zones, and both computers call time(NULL) at the same time, both time()
calls will return the exact same time_t value assuming that the OSs' clocks
are set correctly. Correct?

    2) When a user on the client types in a date, (i.e. "10/15/1997"), I
want to convert this string to a time_t and transmit it to the server. The
server does NOT know the time zone of the client. The client does NOT know
the time zone of the server. My idea is for the client to ALWAYS translate
ALL dates into "GM time" prior to transmitting the data to the server. But
here is my problem:
    If the user enters "10/15/1997", I can parse the string and fill in a tm
structure. However, there is no field in the tm structure representing the
time zone -- so when mktime() is called against the tm structure that I
filled in, mktime() just ASSUMES that the time zone is local. This is a


mktime() to generate its return value based on GM time instead of local
time?

    3) Does standard C++ have a date class? I know that MFC has a date
class, but for this particular project I can't link to MFC. Standard C++
must have SOME kind of date class, but I can't find it for the life of me.

    Thanks for your consideration...
--
and his name was,

David Sworder

    Yes, although it also depends on the system have some indication of what
time zone it is in.  This used to be done via a environment variable, but I
assume now it take the control panel setting.

    The simplest way is to note that the values in the struct tm passed to
mktime, do not need to be in the proper ranges --- mktime will normalize
them first, and then build the time_t.  So, just add the appropriate number
of hours to the tm.tm_hour element to adjust it to UTC.  mktime will deal
with changing the date if necessary.

    Nope,  no Standard date class.  I guess the thinking was that there was
no size specified for time_t, so there nothing stopping an implementation
from making a 64-bit time_t, which would handle dates with second accuracy,
for +/- 4 million years.

    The COleDateTime, i believe, doesn't use any OLE or any other MFC
functions.

    I also have a Date Class available on my website (the second listed
below)

--
Truth,
James Curran
http://www.NJTheater.com
http://www.NJTheater.com/JamesCurran

    Yes, but the question then becomes: "How do I find the number of hours
between my time and UTC?" It's true the VC++ has a _timezone variable that
contains the difference between the local time zone and GM time zone,
expressed in seconds...BUT, that value is only valid TODAY. For example,
right now the value equals 8 hrs. But in April, this value might only be
7hrs because of Daylight Savings.

    So I guess what I'm trying to say is: The trick that you mentioned above
would only work for TODAYs date, but not for some arbitrary date -- unless
you know the DST rules for every location in which your application will be
functioning... Please let me know if I missed something. In the meantime,
I'll check out your date class.

David

Some implementations do this however the C language itself doesn't specify
the representation used by time_t so you souldn't generally assume that
different systems will use the same format.

Maybe, maybe not.

That's reasonable, and as far as I can see from your problem description
the time entered by a user will be a local time so that's no problem.

The return value of mktime() is in the standard format for that particular
implementation. If that happens to be seconds since Jan 1 1970 GMT then that
is what mktime() will return. It is the *input* data that mktime()
always takes as being a local time specification.

--
-----------------------------------------


-----------------------------------------

<< 1) As I understand it, time_t stores the  number of seconds passed since
midnight, Jan 1, 1970 GMT. So, if the client and server are in different
time zones, and both computers call time(NULL) at the same time, both time()
calls will return the exact same time_t value assuming that the OSs' clocks
are set correctly. Correct? >>

Not a safe assumption in most cases. Believe me, you cannot depend on this.
You are better off including synchronization as part of your project.

To solve your problem, simply accept the time and convert it to GMT before
transmitting it. And convert back to local time before displaying the time.
Functions for this purpose are declared in time.h.

You do not need to know the local machine's time zone to convert between
local and GMT, and back (assuming the time zone has been set correctly in
the local machine). Carefully study the functions in time.h. You will see
this is true.

Using the functions in time.h, you can even acquire the time zone in a
machine that does not provide explicit access to this information. This
approach is actually a good idea from a portability standpoint. The only
thing you cannot portably do is *set* the local machine's time zone.

<< Standard C++ must have SOME kind of date class, but I can't find it for
the life of me. >>

Standard C++ does not have an intrinsic date or time class. I believe this
was because the creators of C++ realized just what a can of worms dates and
times are, and decided to leave this up to individual developers.

--

Paul Lutus
www.arachnoid.com