Hello,

Is it possible to move NowUTC from LazUTF8SysUtils.NowUTC to FPC, e.g. DateUtils?

LocalTimeToUniversal(Now) is inefficient and suffers from a race condition, but can still be used as a fallback implementation.

Denis

In our previous episode, Denis Kozlov said:

Isn't that horribly misnamed? It seems to get system time without additional timezone corrections by FPC, but there is no guarantee that that is UTC?

Do you mean "NowUTC" is misnamed? Sure, just as many other things, but consistency is gold-ish ;)

I'm not sure why you say there is no guarantee, because in example of Windows implementation GetSystemTime API is explicitly expressed in UTC according to MSDN.

Denis

In our previous episode, Denis Kozlov said:

I was looking at the Unix implementation.

Unix implementation also returns UTC time, i.e. fpgettimeofday returns seconds since Epoch, which gets converted to TDateTime.

Don't mind another poorly chosen name "EpochToLocal", which in reality is more like "UnixToDateTime".

Is there an issue I'm just not seeing?

Denis

I thought the same. Maybe the implementation predates UnixToDateTime()? Worth a bug report, I think.

Henry

Well, Unix implementation of NowUTC can be replaced with a tidy:

function NowUTC: TDateTime;
var
  tp: timeval;
begin
  fpgettimeofday(@tp,nil);
  Result := UnixToDateTime(tp.tv_sec);
end;

Denis

So, below is a tidy cross-platform implementation of NowUTC:

function NowUTC: TDateTime;
{$ifdef WINDOWS}
var
  SystemTime: TSystemTime;
begin
  Windows.GetSystemTime(SystemTime);
  Result := SystemTimeToDateTime(SystemTime);
end;
{$else}
{$ifdef UNIX}
var
  tp: timeval;
begin
  fpgettimeofday(@tp,nil);
  Result := UnixToDateTime(tp.tv_sec);
end;
{$else}
begin
  // Beware, it suffers from a race condition!
  Result := LocalTimeToUniversal(Now);
end;
{$endif}

Denis

Denis Kozlov wrote

So, below is a tidy cross-platform implementation of NowUTC:

Oops, forgot the milliseconds, here it is:

function NowUTC: TDateTime;
{$ifdef WINDOWS}
var
  SystemTime: TSystemTime;
begin
  Windows.GetSystemTime(SystemTime);
  Result := SystemTimeToDateTime(SystemTime);
end;
{$else}
{$ifdef UNIX}
var
  tp: timeval;
begin
  fpgettimeofday(@tp,nil);
  Result := UnixToDateTime(tp.tv_sec);
  Result := IncMilliSecond(Result, tp.tv_usec div 1000);
end;
{$else}
begin
  // WARNING: Suffers from a race condition!
  Result := LocalTimeToUniversal(Now);
end;
{$endif}
{$endif}

I've uploaded a patch to mantis:
http://bugs.freepascal.org/view.php?id=30394

Denis

Denis Kozlov wrote

I've uploaded a patch to mantis: http://bugs.freepascal.org/view.php?id=30394

Why does your client ignore mailing list threads? (Or why does my Thunderbird email client ignore threads on messages sent from you?)

Ondrej

Ondrej Pokorny wrote

Why does your client ignore mailing list threads? (Or why does my Thunderbird email client ignore threads on messages sent from you?)

I use latest Thunderbird too and Gmail web interface sometimes, but haven't seen this behavior with my threads.

Mailing list archive also shows a correct thread structure: http://lists.freepascal.org/pipermail/fpc-devel/2016-July/thread.html

[image: Inline images 1]

Maybe Thunderbird is having a bad day? Or your mail server is mangling email headers somehow?

Denis

His client doesn't set References: or Reply-to: headers. I have to keep joining the messages to the thread, it's annoying.

Henry

Sorry, meant In-Reply-To:

It's strange. The mailing list archive doesn't show correct thread structure either. Don't you see that your responses to other messages are linked to the root and not to the message you answered? My thunderbird is even worse, it creates new root message of almost all (but not all) of your responses.

Ondrej

Ondrej Pokorny wrote

Why does your client ignore mailing list threads? (Or why does my Thunderbird email client ignore threads on messages sent from you?)

It's replying through Gmail web interface seems to screw it up. Can't use it for mailing lists then. Bummer.

P.S. This one is sent through Thunderbird. Sorry for the mess.

Denis

Can somebody take a look and apply the patch please?

Thanks

Denis Kozlov wrote

I've uploaded a patch to mantis: http://bugs.freepascal.org/view.php?id=30394 Denis

Denis Kozlov wrote

Can somebody take a look and apply the patch please?

I had a modify the patch first, see comments in bugreport.

Michael.

Michael Van Canneyt wrote

I had a modify the patch first, see comments in bugreport.

The reason why I put UniversalTime (a.k.a. NowUTC) function in DateUtils is because of the dependency on LocalTimeToUniversal, UnixToDateTime, IncMilliSecond functions.

I presumed that DateUtils cannot (or must not) be added to the uses section of SysUtils.

What would you recommend?

Denis

As far as I can see, these perform almost the same function as EpochToLocal in sysutils/unix.

You can perfectly do these additions manually.

I presumed that DateUtils cannot (or must not) be added to the uses section of SysUtils.

Indeed it cannot.

What would you recommend?

I don't see why you cannot perform simple additions in sysutils.

The reverse, introducing system dependent system calls in dateutils, is a much worse solution. DateUtils is for simple date/time calculations, not for performing OS calls.

Michael.

Michael Van Canneyt wrote

I don't see why you cannot perform simple additions in sysutils.

But that would create duplicated code of LocalTimeToUniversal, UnixToDateTime, IncMilliSecond functions in SysUtils and DateUtils.

As far as I can see, these perform almost the same function as EpochToLocal in sysutils/unix.

EpochToLocal is equivalent to UnixToDateTime, except the later is more efficient and better named. Also, I found at least 4 copies of EpochToLocal in RTL for some reason, one of which suggests to use UnixToDateTime instead ;)

Assuming that UniversalTime function must reside in SysUtils, I see these options:

* Option A: Duplicate necessary functions from DateUtils to SysUtils.
* Option B: Move necessary functions from DateUtils to SysUtils.
* Option C: Include DateUtils in RTL, so that we cant use its functions in SysUtils.

Option C seems to be the cleanest. Am I wrong to think that?

Denis

Denis Kozlov wrote

On 30/07/2016 17:45, Michael Van Canneyt wrote: > I don't see why you cannot perform simple additions in sysutils. But that would create duplicated code of LocalTimeToUniversal, UnixToDateTime, IncMilliSecond functions in SysUtils and DateUtils.

So what ? It is essentially A+B*C or some variant of that.

Since you seem reluctant, no problem, I will do it myself.

Michael.

Michael Van Canneyt wrote

But that would create duplicated code of LocalTimeToUniversal, UnixToDateTime, IncMilliSecond functions in SysUtils and DateUtils. So what ? It is essentially A+B*C or some variant of that.

I try to avoid code duplication, which unnecessarily increases maintenance efforts.

Since you seem reluctant, no problem, I will do it myself.

I'm asking for guidance to make sure I do it the right way.

Is it really so bad to include DateUtils in RTL?

Denis

One must weigh always weigh the advantages over the disadvantages. Consistency and design of the API have also their purpose.

If I didn't care about that, I would simply have added it to dateutils. As it is now, dateutils is 100% portable. By introducing a dependency on the OS, this is no longer true, and I think that should be avoided.

> Since you seem reluctant, no problem, I will do it myself. I'm asking for guidance to make sure I do it the right way.

In that case, just copy the implementation of the functions involved.

Is it really so bad to include DateUtils in RTL?

Yes. It was specially removed to keep the RTL as small as possible.

To move it back for the sake of some multiplications and additions is not an option IMHO.

Michael.