Prev: Please help, how do I fix error C4346 with the code here...
Next: Memory acces completely optimized away
From: neilsolent on 28 Oct 2009 06:00
Hi All

How can I read/write 4-byte wide timestamps to files in GMT, ignoring
any local timezone?
i.e. I want versions of utime() and stat() that work only in GMT.

To demonstrate what I mean..

Run this program in the UK at 01:59 on 25/10/09 (when the local
timezone is GMT+1):

<code>
#include "stdafx.h"
#include <sys/utime.h>

int main(int argc, char* argv[])
{
struct _utimbuf ver;
ver.modtime = 0;
ver.actime = 0;
_utime("test", &ver);
return 0;
}
</code>

C:\temp>dir test
Volume in drive C has no label.
Volume Serial Number is 5028-7113

Directory of C:\temp

01/01/1970 00:00 7 test
1 File(s) 7 bytes
0 Dir(s) 34,768,842,752 bytes free



Wait 2 minutes (local timezone changes to GMT+0) and:



C:\temp>dir test
Volume in drive C has no label.
Volume Serial Number is 5028-7113

Directory of C:\temp

31/12/1969 23:00 7 test
1 File(s) 7 bytes
0 Dir(s) 34,768,842,752 bytes free




This differs from how utime() works on UNIX. The UNIX man pages say:

" The times contained in the members of the utimbuf structure
are measured in seconds since 00:00:00 UTC, January 1, 1970. "

The Windows version seems to be taking into account the current
timezone when these commands are run. I need to turn this behaviour
off.


Thanks,
Neil
From: David Lowndes on 28 Oct 2009 08:54
>The Windows version seems to be taking into account the current
>timezone when these commands are run. I need to turn this behaviour
>off.

Neil,

What do you get if you run the program again when at the UTC time
zone?

I think you're just seeing a quirk. On NTFS the file timestamps are
stored as UTC, and the facilities of the OS (usually) display the
value as local time - that's why the timestamp displays differently
when viewed from different time zones.

Dave
From: neilsolent on 28 Oct 2009 09:07

Dave
Thanks for the reply.

> What do you get if you run the program again when at the UTC time
> zone?
It sets the time to "01/01/1970 00:00" - as I would expect.

I am happy with the output - I can see why it is what it is. I don't
think it is a bug - it is just not the behaviour I want!

When the program sets the time to "0" with the local timezone set to
GMT+1, it is setting "01/01/1970 00:00" in the local timezone - which
is actually "31/12/1969 23:00" in GMT (as GMT is one hour behind).
The output of dir is correct as well - again reporting dates and times
in the current timezone.
I just want to tell utime() to interpret 0 as "0 GMT" NOT "0
LOCALTIME". But I can't think of a neat way of doing it!

I don't want to look up the current timezone and add correction
factors - apart from being a load of messy code - it would be hard to
avoid a race condition if the code is run close to the moment a
timezone is changed. I naturally assume Windows does everything
natively in GMT (UCT) internally anyway - so there should be a simpler
way

From: David Lowndes on 28 Oct 2009 10:06
>I just want to tell utime() to interpret 0 as "0 GMT" NOT "0
>LOCALTIME". But I can't think of a neat way of doing it!

I'd use the Win32 SetFileTime API instead and convert between local
and system time as appropriate using LocalFileTimeToFileTime &
FileTimeToLocalFileTime .

Dave
From: neilsolent on 28 Oct 2009 15:01
On 28 Oct, 14:06, David Lowndes <Dav...(a)example.invalid> wrote:
> >I just want to tell utime() to interpret 0 as "0 GMT" NOT "0
> >LOCALTIME". But I can't think of a neat way of doing it!
>
> I'd use the Win32 SetFileTime API instead and convert between local
> and system time as appropriate using LocalFileTimeToFileTime &
> FileTimeToLocalFileTime .
>
> Dave

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.
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
 |  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