packtimeqq 'feature'

packtimeqq 'feature'

I just wasted a chunk of my life due to an 'inconsistency' in packtimeqq.

if I evaluate:

call packtimeqq(i1,int2(2014),int2(3),int2(1),int2(1),int2(1),int2(1))

and

call packtimeqq(i1,int2(2014),int2(4),int2(1),int2(1),int2(1),int2(1))

I would have expected a differance of 31x24x60x60 seconds (a 31 day month)

I get a discrepancy of 3600s (1 hour). I assuming from this  that packtimeqq assumes the you are passing in data that is in the time zone of the pc you are on. I am in the UK and beween those dates there would be a 'daylight saving' shift of 1h from GMT to BST. 

In may case the date/time I am using is always in GMT(UTC) so this adjustment can lead to errors so I will need to change my code.

1] Is this the case that packtimeqq does this?

2] If so there should be a note in the help file for this routine.

 

 

6 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

You are correct - PACKTIMEQQ uses the local computer's timezone and rules for daylight savings. It is essentially a wrapper to the c mktime function, with the "isdst" field set to -1 to indicate "unknown" as to whether daylight savings is in effect. I will ask our writers to add a note about this here and in the description of UNPACKTIMEQQ.  Issue ID is DPD200241161.

Steve - Intel Developer Support

Thanks Steve, for the record I also noted that:

call packtimeqq(i1,int2(1969),int2(3),int2(1),int2(1),int2(1),int2(1))

returns -1, which is OK as an error flag for dates before the epoch

call packtimeqq(i1,int2(2014),int2(13),int2(32),int2(25),int2(61),int2(61))

That one is more amusing as day 32 of month 13 returns a value that is sort of valid for about that time period. To my mind it should return a value of -1 aslo, garbage in, garbage out.

I guess there might be an error flag in the geterrorqq but I didn't check, there is no indication in the help. 

to work around it was easier for my purposes to write my own date packer, which I now have.

 

PACKTIMEQQ literally is just a wrapper to mktime - it fills in the "tm" structure with the values you give it and calls mktime. If mktime doesn't do the check, then you get no error.  It has no error processing of its own.

Steve - Intel Developer Support

Yup I get that "The values of the members tm_wday and tm_yday of timeptr are ignored, and the values of the other members are interpreted even if out of their valid ranges (see struct tm). For example, tm_mday may contain values above 31, which are interpreted accordingly as the days that follow the last day of the selected month."

I don't have a problem with that but it seems strange that the MS C++ guys take meaningless data and try to make a valid answer, hey ho. :-)

Hey, it's C - what do you expect? :D

Steve - Intel Developer Support

Kommentar hinterlassen

Bitte anmelden, um einen Kommentar hinzuzufügen. Sie sind noch nicht Mitglied? Jetzt teilnehmen