Remove call of localtime

[beutlich]

There is a race condition between localtime and ftime/gettimeofday in ModelicaInternal_getTime. In case ftime/gettimeofday is called at a very new second, this can lead to an inaccuracy of (almost) 1 second for the calculated time.

Using gmtime, there is no need to call localtime. Instead the struct tm can be directly computed from the obtained timebuffer and timezone information.

[HansOlsson]

The ftime handling of time-zones and DST is not clear to me, and thus I am not sure if it is worth the effort.

In detail: as far as I can tell POSIX has removed ftime, and Microsoft does in
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/ftime-ftime32-ftime64?view=vs-2019 refer to
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=vs-2019
which claims that US rules for DST are used, so it is not clear that it is currently useful in Europe.

In particular it is not clear if it is just a flag, or whether other values that 0 and 1 are intended for odd cases (two hour DST, 20 minute DST etc).

(Oh, and for POSIX it isn't even clear if the DST-flag indicates the presence of DST some time during the year or whether is currently active.)

[sjoelund]

Wouldn't it just be easier to copy the tm struct to avoid the race condition? struct tm a = *localtime(&t);, etc? I assume this only happened for the non-secure/re-entrant versions of localtime?

[beutlich]

It's about the two different calls to timing functions:

1. localtime to retrieve the tm struct w/o seconds and
2. ftime/gettimeofday to retrieve the milli- or mircoseconds
   On average, every 1000th call is 1 second of from the actual time since the microseconds of a new second are reported for the previous second.

I am not sure if relevant at all or if the proposed changes are good enough, but what I did:

• Avoid ftime for POSIX (since deprecated) and use gettimeofday.
• Do not use tz.tz_dsttime from gettimeofday and rely that DST offset is considered by tz_minuteswest.
• Consider non-zero dstflag for 1 hour DST offset. (Can test after 2020-03-29 if it works in Europe, too.)

[CLAassistant]

All committers have signed the CLA.

[HansOlsson]

What is the status of this one?
I noticed that:

• There are some comments indicating other changes - that I don't see in this PR.
• It still exists (don't know for which version), and is in my review queue.
• There were some tests that should be done after 2020-03-29 (and before sometime in the autumn). I don't know their status.

[beutlich]

What is the status of this one?

Thanks for reminding me.

Wouldn't it just be easier to copy the tm struct to avoid the race condition?

There is no milliseconds or microseconds in struct tm. Therefore there are two different calls to determine current time in current code. This should be avoided. In the PR I also test for dstflag != 0 only.

The ftime handling of time-zones and DST is not clear to me

The dstflag is nonzero if DST is currently in effect for the local time zone. That is what I tested in DST (now) and 7 months ago (when DST was not in effect).

I can tell POSIX has removed ftime

Yes. gettimeofday is used in the PR for that reason.

so it is not clear that it is currently useful in Europe

I tested successfully in CET with and without DST in effect.

In particular it is not clear if it is just a flag

It is used as a flag.

(Oh, and for POSIX it isn't even clear if the DST-flag indicates the presence of DST some time during the year or whether is currently active.)

Yes, would be good to get some feedback from POSIX expert @sjoelund if the code is formally correct and if it can be successfully tested.

[beutlich]

@HansOlsson @sjoelund Any ideas how to proceed?

[HansOlsson]

@HansOlsson @sjoelund Any ideas how to proceed?

I think it is ok, but want to hear from @sjoelund

[HansOlsson]

Ok, then.

[HansOlsson]

@beutlich Is there a reason to not merge this? (Apart from resolving the conflict).

[beutlich]

(Apart from resolving the conflict)

Done.

[HansOlsson]

@beutlich can you update this from master? I did it like 7 minutes ago, but it is still out of sync and it invalidates my review.

[beutlich]

@beutlich can you update this from master? I did it like 7 minutes ago, but it is still out of sync and it invalidates my review.

Done once again.