Prev: Please help, how do I fix error C4346 with the code here...
Next: Memory acces completely optimized away
From: Nathan Mates on 28 Oct 2009 16:24
In article <a1bb476c-7205-4d7d-80e2-6eb04b50bf84(a)u16g2000pru.googlegroups.com>,
neilsolent <n(a)solenttechnology.co.uk> wrote:
>I start with the time in "seconds since midnight, Jan 1st 1970" format
>(time_t) - I don't think there is any simple way to convert to/from
>FILETIME.

Yes there is.
http://msdn.microsoft.com/en-us/library/ms724228(VS.85).aspx shows how
to go from time_t to FILETIME. If you look closely, it's basically
filetime = (X * time) + Y. Reversing the operation is simple algebra.

Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
From: David Lowndes on 28 Oct 2009 16:39
>I start with the time in "seconds since midnight, Jan 1st 1970" format
>(time_t) - I don't think there is any simple way to convert to/from
>FILETIME.

You can do it, but it may take a couple of hops. The COleDateTime
class may wrap enough of this functionality to make it look simple.
However...

>And there's still the issue of avoiding nasty outcomes at the moment
>that the timezone changes.
>Filesystems are always in UTC - seems annoying that I can't just read/
>write the time directly in UTC without the complication of the local
>time zone getting in the way

The way it normally works is this:

A user (normally) likes to work in their local time.
The internals work in UTC.

.... so wherever there's a transition between the 2 you perform the
appropriate local/utc conversion.

If the user has entered the time initially, convert it to UTC then
save it. When reading back to present to the user you go from UTC to
local.

Have a look at the MSDN knowledge base article 932955 "How to handle
dates and times that include DST" - that seems to explain the
situation.

Dave
From: neilsolent on 30 Oct 2009 05:57
ALL

Thanks for the posts. I had overlooked that SetFileTime() and
GetFileTime() naturally work in GMT, which simplifies things and I
agree is th best approach.
My code now works.

One further question - is there an inverse function to this:

void TimetToFileTime(time_t t, LPFILETIME pft)

... I need to convert FILETIME back to time_t in another part of the
code.

Thanks again

From: David Lowndes on 30 Oct 2009 06:48
>Thanks for the posts. I had overlooked that SetFileTime() and
>GetFileTime() naturally work in GMT, which simplifies things and I
>agree is th best approach.
>My code now works.

Good :)

>One further question - is there an inverse function to this:
>
>void TimetToFileTime(time_t t, LPFILETIME pft)
>
>.. I need to convert FILETIME back to time_t in another part of the
>code.

I can't immediately find one to copy, but that example on MSDN is only
simple maths, so just to the inverse operations.

Dave
From: neilsolent on 30 Oct 2009 14:43
> I can't immediately find one to copy, but that example on MSDN is only
> simple maths, so just to the inverse operations.

Just to wrap this thread up - and for future ref - here's my
implementation of this function:

void FileTimeToTimet(LPFILETIME pft, time_t* t)
{
*t = (((pft->dwHighDateTime - 27111902) << 32) - 3577643008 + pft-
>dwLowDateTime) / 10000000;
}

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Please help, how do I fix error C4346 with the code here...
Next: Memory acces completely optimized away