mktime or MakeDateTime?

[holly7787]

what do you prefer?

MakeDateTime has 2035 year limit but is easier to use.

mktime use a struct, maybe more complete, but more difficult.

also how do you handle DST? if you don't have the UTC time is impossible to know if a file where stored in DST or not, am i correct?

there are other time format that i don't know?

thank you

[blakney]

In order to help, an explanation of the problem that needs to be solved would help to put an answer into context.

On connected computers, UTC is fairly easy to retrieve. Do you need sub second precision? If so, how precise?

I'll propose one simple example that might fit.

If one was trying to determine the age of a file stored on a local computer relative to current time, one could assume that the file was created on the same computer (and has the same time zone.) I guess you might want to verify that a daylight savings time conversion had not occurred. 

(Note: If one is worried that a user is tampering with system clock, this will not help at all. UTC might help but is still no guarantee.)

[holly7787]

sorry for the delay in the response.

i'm making a production management software and i'm worried about "race condition" saving the result only in local time.

also i'm worried that my machine in the year 2035 will stop saving data correctly if using MakeDateTime, this problem will happen in 17 year from now so it's not so far.

[blakney]

I would honestly make the jump to time_t struct based code. It is not that hard. I just fumbled around in a test program until I got it sorted.

localtime() works with time_t and gets you back to your time zone when needed.

Greg

[Mattia.G]

Hi Davide Vittorio,

Also I am looking for an alternative to MakeDateTime due to the limit in 2035. I looked at mktime but it has the same problem in 2038.

Have you found a solution to this problem?

Mattia Guerra
Italian SW Developer

[holly7787]

Hi Mattia, I haven't found a solution to this problem.

There is NI time format that is 64 bit and will not have problem, but it's more complecated to manage.

Maybe compiling at 64 bit instead of 32 will solve the problem with timeformat.

the good thing is that we are safe for other 14 years!

[Mattia.G]

Hi Davide Vittorio,

So the only solution is to use NI-BTF and related functions like CVIAbsoluteTimeFromLocalCalendar, SubtractCVIAbsoluteTimes, CVITimeIntervalToSeconds, etc.

 I will try to use these functions because 2035 is too close.

Thanks for your Reply.

[RobertoBozzolo]

Hello all, as you can see by looking at time.h file time_t is actually version dependent: on a 64-bit executable it is a 64-bit integer so it does not suffer from year 2038 problem.

Look at the small sample attached.

(ho lasciato le scritte in italiano ma non credo sia un problema: siamo tutti nel Bel Paese, no? 😉 )

[holly7787]

as i was thinking but didn't go deeper with the analysis!

Ciao Roberto, mitico come sempre!