C / C++ / MFC

7-Jan-14 0:55

I have 3 files (bitmap files) which has the modified date:

file1.bmp ------- 9/19/2013 01:02 PM
file2.bmp ------- 9/20/2013 07:57 PM
file3.bmp ------- 11/21/2013 10:39 AM

that is what windows explorer show me in XP ... ok, but in Win7, windows explorer show

file1.bmp ------- 9/19/2013 02:02 PM (+1 hour)
file2.bmp ------- 9/20/2013 08:57 PM (+1 hour)
file3.bmp ------- 11/21/2013 10:39 AM

The first two of them has the date before DST (October 2013), and last one after DST (October 2013), but this issue exist only in Win7.

The issue come when I try to get file modified datetime, with follow code:

C++

CFileStatus status;
CFile::GetStatus(sPath, status);

CTime time(status.m_mtime);
TRACE("%d:%d - %s\n", time.GetHour(), time.GetMinute(), sPath);

which show me the modified dates like XP does:

C++

13:2 - file1.bmp
7:57 - file2.bmp
10:39 - file3.bmp

but if I run this code on Win7, I have a problem with first two files: show me modified date less by one hour than windows explorer does (as I said in Win7) .... how can I fix this issue ? Does anyone faced with this kind of problem ?

Thank you.

Richard MacCutchan7-Jan-14 2:53

7-Jan-14 2:53

I'm not sure what this has to do with C++, but you should check your regional settings for date and time and timezone in both systems.

Veni, vidi, abiit domum

Jochen Arndt7-Jan-14 3:02

7-Jan-14 3:02

The CTime class represents dates and times in UTC (the filetime stored on the disk is also UTC). If you want to show local times you must convert the timestamp. This can be done using localtime() and SystemTimeToTzSpecificLocalTime(). Depending on the timezone, the times shown by the Explorer of different Windows versions may be not identical. When using an old OS version without updated DST information and the DST switch dates has been changed, it may show wrong values.

EDIT:

Quote:
the filetime stored on the disk is also UTC

is wrong and must be: 'the filetime stored on NTFS partitions is also UTC'.

FAT uses local times. See also File Times[^] in the MSDN.

_Flaviu7-Jan-14 21:45

7-Jan-14 21:45

Unfortunately, I didn't succeeded, using below code:

C++

CTime time2(status.m_mtime);
time_t tt = time2.GetTime();
struct tm* timeinfo;
timeinfo = localtime(&tt);
time_t tt2 = mktime(timeinfo);
CTime time3(tt2);
SYSTEMTIME stUTC, stLocal;
time3.GetAsSystemTime(stUTC);
TIME_ZONE_INFORMATION tzi;
GetTimeZoneInformation(&tzi);
SystemTimeToTzSpecificLocalTime(&tzi, &stUTC, &stLocal);
CTime time4(stLocal);
TRACE("%d:%d\n", time4.GetHour(), time4.GetMinute());

the dates less than october 2013 is incremented by 3 hours, and date greater than october 2013 is incremented by 2 ... according by first post:

file1.bmp --- 16:2
file2.bmp --- 10:57
file3.bmp --- 12:39

I did something wrong ?

Last edit: the file system is NTFS.

modified 8-Jan-14 4:15am.

Richard MacCutchan7-Jan-14 22:06

7-Jan-14 22:06

Flaviu2 wrote:
dates less than october 2013 is incremented by 3 hours, and date greater than october 2013 is incremented by 2

That sounds correct, the ones before October have daylight savings added to them. As I said before, you should check your regional timezone sttings.

Veni, vidi, abiit domum

Jochen Arndt7-Jan-14 22:39

7-Jan-14 22:39

The dates before october have DST enabled and so an additional hour is expected. The offset without DST is 2 hours. So your time zone is EET.

The trace output from your previous post corresponds to:

2013-09-19 16:02 EEST
2013-09-20 10:57 EEST
2013-11-21 12:39 EET

Converting these to UTC/Zulu matches the trace output of your initial post:

2013-09-19 13:02 Z
2013-09-20 07:57 Z
2013-11-21 10:39 Z

The dates shown by Windows XP from your initial post:

file1.bmp ------- 9/19/2013 01:02 PM
file2.bmp ------- 9/20/2013 07:57 PM
file3.bmp ------- 11/21/2013 10:39 AM

This is identical to UTC (assuming 07:57 PM should be AM). So it seems that your Windows XP is configured to use UTC/Z (which does not use DST).

The dates shown by Windows 7 from your initial post:

file1.bmp ------- 9/19/2013 02:02 PM (+1 hour)
file2.bmp ------- 9/20/2013 08:57 PM (+1 hour)
file3.bmp ------- 11/21/2013 10:39 AM

It seems that your Windows 7 is configured to use GMT which uses DST.

So all dates match when using the above time zones (and assuming that the PM of file2 should be AM).

_Flaviu8-Jan-14 1:14

8-Jan-14 1:14

Well, I am working on Win7, which have Automatically adjust clock for Daylight Saving Time option checked, file system is NTFS. Here, I read (in windows explorer):

C++

file1.bmp ------- 9/19/2013 02:02 PM (+1 hour)
file2.bmp ------- 9/20/2013 08:57 PM (+1 hour)
file3.bmp ------- 11/21/2013 10:39 AM

And I have an virtual machine, where I had installed an XP SP3 (for testing purpose). This system also have Automatically adjust clock for daylight saving changes option checked, and you are right, I read follow values (in windows explorer):

C++

file1.bmp ------- 9/19/2013 01:02 PM
file2.bmp ------- 9/20/2013 07:57 PM
file3.bmp ------- 11/21/2013 10:39 AM

The file system is NTFS as well.

I have to digg in ...

Jochen Arndt8-Jan-14 1:33

8-Jan-14 1:33

It would be interesting to know which time zone is set in both (right click on time in task bar, change date/time, change time zone). On my German Windows 7 and the virtual XP3 there are multiple entries for UTC/GMT: With city names and one labelled 'Universal Time'. The last one is plain UTC (called Zulu) without DST. It seems that your XP has this set.

_Flaviu8-Jan-14 1:44

8-Jan-14 1:44

On my Window 7 I have time zone:

(UTC + 2) Athens, Bucharest, Istanbul
Automatically adjust clock for Daylight Saving Time checked

On my virtual XP SP3 I have:

C++

(GMT + 2) Bucharest
Automatically adjust clock for daylight saving clock checked

In both of them I have the same hour (2:43 PM is now) as well ...

Jochen Arndt8-Jan-14 2:13

Re: File time issue [solved]

8-Jan-14 2:13

That looks OK. But for some reason your Explorer uses different time zones (GMT/UTC rather than EET of the systems). What if you create a new file now? According to your previous posts, the Explorers would show a two hour offset.

But that should not be the case (from How to handle dates and times that include DST[^]):

Quote:
For example, Windows Explorer applies the time zone and the DST setting to the UTC timestamp before it displays dates and times for files in a Windows NT File System (NTFS) directory.

I suggest to read the full text. It contains a block that explains that the Explorer may show different times.

Reading the above, there is a possible reason for your observations:
XP uses the current time zone and DST state to display the time stamp. So there is no additional hour for dates with DST because DST is not active today. With Vista, dynamic time zones has been introduced. When the Explorer of Windows 7 uses them, it may show the time stamp with DST offset.

_Flaviu9-Jan-14 2:11

Re: File time issue [solved]

9-Jan-14 2:11

I finally made it:

C++

CFileStatus status;
CFile::GetStatus(sPath, status);

SYSTEMTIME systimeFile;
status.m_mtime.GetAsSystemTime(systimeFile);
COleDateTime dt(systimeFile);

if(m_bGreaterThanXP)
{
    TIME_ZONE_INFORMATION tzi;
    DWORD dwTZI = GetTimeZoneInformation(&tzi);
    if(dwTZI == TIME_ZONE_ID_STANDARD || dwTZI == TIME_ZONE_ID_DAYLIGHT)
    {
        SYSTEMTIME stLocal;
        SystemTimeToTzSpecificLocalTime(&tzi, &systimeFile, &stLocal);
        COleDateTime dtLocal(stLocal);
        COleDateTimeSpan span(0, 0, (int)tzi.Bias, 0);
        dt = dtLocal + span;
    }
}

CString sTime = dt.Format(VAR_TIMEVALUEONLY);

where bGreaterThanXP is retrieved like that:

C++

m_bGreaterThanXP = FALSE;

OSVERSIONINFO osvi;
ZeroMemory(&osvi, sizeof(OSVERSIONINFO));
osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
GetVersionEx(&osvi);
 if(osvi.dwMajorVersion > 5)
     m_bGreaterThanXP = TRUE;

hope to help on somebody ... thank you all !

P.S. Please correct me if I did something wrong.

modified 9-Jan-14 8:28am.

Jochen Arndt9-Jan-14 3:30

Increment and Decrement Operators

9-Jan-14 3:30

Fine that you have solved it and thank you for the feedback.

tgsb6-Jan-14 20:57

tgsb

6-Jan-14 20:57

Hi everyone....this Increment(++) and Decrement(--) operators in C topic is really one of the surprise topic for me as I always get some surprise with their answer. The time I thought I got the concept of this topic I find my self wrong with its next question. I want to know what is its actual concept and whats the best approach to solve inc and dec operator questions. Make me understand with an example. Appreciate your suggestion and help. Thanks

Richard MacCutchan6-Jan-14 22:00

6-Jan-14 22:00

These operators merely add (inc) or subtract (dec) 1 from the item in question. If the operator is used in the postfix position (i++) then the original value is returned. If the operator is used in the prefix position (--i) then the new value is returned. Thus:

C++

int i = 10;
int result;
result = i++;  // result equals 10, i equals 11
result = ++i;  // result equals 12, i equals 12
result = i--;  // result equals 12, i equals 11
result = --i;  // result equals 10, i equals 10

// note do not use expressions such as
result = ++i + i++; // results undefined

Veni, vidi, abiit domum

Suk@nta7-Jan-14 0:27

Suk@nta

7-Jan-14 0:27

hey i want to rectify Message send by Richard MacCutchan

int i = 10;
int result;
result = i++;  // result equals 10, i equals 11
result = ++i;  // result equals 12, i equals 12
result = i--;  // result equals 12, i equals 11
result = --i;  // result equals 10, i equals 10

// note do not use expressions such as
result = ++i + i++; // results undefined

As written the last line gives output undefine i think its wrong .it will give correct output as 23.
If u had checked then u already got the result.
here i will explan u how it's work..

1:from left to right ++i changes i values 10 to 11.
2:then it will add 11 + 11 (as i++ is post increment operator it will execute after expression execution) and gives result as 22
3: then i values becomes 22 and i++ will going to execute and i value changes to 22+1=23

Richard MacCutchan7-Jan-14 0:35

7-Jan-14 0:35

I'm sorry but it is a well known fact that in expressions like this, the compiler is not constrained to follow the rules as you see them. Using multiple increment decrement operators in a single expression is not guaranteed to produce the result you expect and should not be used.

Veni, vidi, abiit domum

Marco Bertschi7-Jan-14 1:27

Marco Bertschi

7-Jan-14 1:27

An undefined behavior often means that the compiler may crash, and if not it behaves like it thinks it should, which isn't necessarily the same on different compilers.

Veni, vidi, caecus | Everything summarizes to Assembly code

Richard MacCutchan7-Jan-14 2:48

7-Jan-14 2:48

Yes. My comments were an over-simplification, but it is still worth avoiding expressions of that sort.

Veni, vidi, abiit domum

Marco Bertschi7-Jan-14 9:41

Marco Bertschi

7-Jan-14 9:41

Richard MacCutchan wrote:
but it is still worth avoiding expressions of that sort.

Every respectable Dev must avoid it.
By the way, my comment was intended to be an addition to yours.

Veni, vidi, caecus | Everything summarizes to Assembly code

Richard MacCutchan7-Jan-14 21:55

7-Jan-14 21:55

Marco Bertschi wrote:
my comment was intended to be an addition to yours.

Yes, that was how I understood it. Thumbs Up | :thumbsup:

Veni, vidi, abiit domum

David Crow7-Jan-14 16:43

David Crow

7-Jan-14 16:43

sukanta kumar mangal wrote:
As written the last line gives output undefine i think its wrong .it will give correct output as 23.
If u had checked then u already got the result.
here i will explan u how it's work..

At a minimum, you might want to brush up on sequence points.

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous

Ron Beyer7-Jan-14 17:27

Ron Beyer

7-Jan-14 17:27

I'll explain why the behavior is undefined...

This has a lot to do with operator precedence[^], see the ++ as a prefix operator has an equal precedence to the + operator. Its up to the compiler to determine which one to evaluate first, since they are at an equal precedence there is no universal "++(pre) before +".

However, ++ as a postfix operator has a higher precedence than the prefix operator, so for example:

i = 10
result = ++i + i++;

Turns into
result = ++i + 11;

Now, the compiler really doesn't care which one is evaluated first, the + or the ++. Each one is free to implement it as they see fit, so it might be 22 or it might be 23, it depends on which one the programmer handled first.

Suk@nta7-Jan-14 19:27

Suk@nta

7-Jan-14 19:27

no no..in any compiler prefix operator execute first than postfix.
postfix will execute after value returned or assigned to some variable..

Richard MacCutchan7-Jan-14 21:59