GetData millisec always zero

Monkey Forums/Monkey Bug Reports/GetData millisec always zero

ziggy

(Posted 2014) [#1]

When using it on GLFW, the millisec component of getdate is always zero.

Shinkiro1

(Posted 2014) [#2]

I wondered about this too and as it turns out the function in the glfw source returns 0.

ziggy

(Posted 2014) [#3]

But this can't be right! I mean, shouldn't this be returning proper results?

therevills

(Posted 2014) [#4]

This is the date code in "gametarget.cpp":

void BBGame::GetDate( Array<int> date ){
	int n=date.Length();
	if( n>0 ){
		time_t t=time( 0 );
		
#if _MSC_VER
		struct tm tii;
		struct tm *ti=&tii;
		localtime_s( ti,&t );
#else
		struct tm *ti=localtime( &t );
#endif

		date[0]=ti->tm_year+1900;
		if( n>1 ){ 
			date[1]=ti->tm_mon+1;
			if( n>2 ){
				date[2]=ti->tm_mday;
				if( n>3 ){
					date[3]=ti->tm_hour;
					if( n>4 ){
						date[4]=ti->tm_min;
						if( n>5 ){
							date[5]=ti->tm_sec;
							if( n>6 ){
								date[6]=0;
							}
						}
					}
				}
			}
		}
	}
}

With date[6]=0, it will always be zero.

Compared to the Flash gametarget.as:

if( n>6 ){
	date[6]=t.getMilliseconds();
}

Monkey uses ctime for cpp which is only precise to the second.

Nobuyuki

(Posted 2014) [#5]

one thing to note then: Don't rely the millisecs number from GetDate() for adding entropy to the randomizer's seed if you're on desktop. Using Millisecs() in combination with GetDate() should be slightly better

ziggy

(Posted 2014) [#6]

I'm developing a clock app for one client (yes, there are people that pay for this!) and I was expecting different behavior on GLFW. This should be noted in the docs.