Why does GetCurrentUtcOffset uses now ?

[CharlieDuga]

Hi,

Thank you for your amazing work, it's very useful.

I have a suggestion about your tzdb.pas library.
I have UTC time and a timezone name as input. I'd like to retrieve the offset between UTC and the timezone, without being machine-dependent.
The GetUtcOffset function seems suitable for this, but it takes a local time as input, not a UTC time. I don't understand why a local time is needed to find an offset between two other times.
I managed to get around this by giving it a local time as a parameter, which I recalculate from ToLocalTime and my UTC time.
It would be useful to be able to distinguish between two types of calls to GetUtcOffset, depending on whether the input is a local time or a UTC time.

Thank you in advance for your feedback.

Charlie

[pavkam]

Hi Charlie,

Thanks for the kind words. Regarding your query: the UTC offset will vary across the year (depending of the time zone). The UTC time, by definition has an offset of zero.

You can obtain the year segments for a given year and get the UTC offset from them.

Your current approach is problematic since the offset you will get will differ during the year so you need to rethink what exactly you need the offset for.

Hope this helps,
Alex.

[CharlieDuga]

Thanks for your reply.

My problem is that I can't know the segment because I don't know what local time it is in the TimeZone (which is different on my local machine).
For example, my local machine is Europe/Paris and the TimeZone that I want to know the local time is America/New_York.
I only know UTC Time right now and not the local time in New York. I need the real offset for that.

Charlie

[pavkam]

Thanks for your reply.

My problem is that I can't know the segment because I don't know what local time it is in the TimeZone (which is different on my local machine).
For example, my local machine is Europe/Paris and the TimeZone that I want to know the local time is America/New_York.
I only know UTC Time right now and not the local time in New York. I need the real offset for that.

Charlie

Convert UTC time to local time in that Timezone and you can then get the offset. Just note that if you do that in winter you will get a different offset compared to doing that in summer.

Usually, when dealing with local time you should never assume you "know" the offset.

But

[CharlieDuga]

My application performs all its calculations using UTC time (because it's universal) and user configuration is done in local time for each user (which can therefore be different depending on the user).
I know that the offset will be different depending on the time of year, and that's exactly what I want.
I simply want to know the offset of a specific time zone at a specific time to perform a calculation at that time.

So I'm going to use the local time conversion before being able to use the GetUtcOffset function.

That's why I think it would be useful to be able to call a GetUtcOffset function directly with a UTC time, to abstract this conversion.

Charlie

[zedxxx]

That's why I think it would be useful to be able to call a GetUtcOffset function directly with a UTC time, to abstract this conversion.

And this will break all existing code. On the other hand, even if you write some alternative function that takes UTC time as input, it would still have to call ToLocalTime under the hood to get the offset.

As for me, I don't see much of a problem here, and the current behavior seems perfectly fine.

[zedxxx]

As for using Now in GetCurrentUtcOffset (and other functions), I think there's room for a bug here. It should be something like this:

function TBundledTimeZone.GetCurrentLocalTime: TDateTime;
begin
  Result := ToLocalTime(TTimeZone.Local.ToUniversalTime(Now));
end;

function TBundledTimeZone.GetCurrentUtcOffset: {$IFDEF DELPHI}TTimeSpan{$ELSE}Int64{$ENDIF};
begin
  Result := GetUtcOffset(GetCurrentLocalTime);
end;

After all, Now is the system local time, not the local time of the given time zone.

[CharlieDuga]

Yes, that's my point :)

I wasn't sure about the meaning of current. Is it the application's system or the TBundledTimeZone object we're in ?

Until now, calling now directly takes the current time from the application's system, but your analysis seems to indicate that it should be the current time of the TBundledTimeZone object, which is what I'm looking for.

[pavkam]

Yes, that's my point :)

I wasn't sure about the meaning of current. Is it the application's system or the TBundledTimeZone object we're in ?

Until now, calling now directly takes the current time from the application's system, but your analysis seems to indicate that it should be the current time of the TBundledTimeZone object, which is what I'm looking for.

TBundledTimeZone operates on "local time in that timezone". Only ToLocalTime allows converting from UTC to the local time in that TZ. Other than that it's all "local time".

To get the Offset of an UTC time, what you did is the way to go: Zone.GetUtcOffset(Zone.ToLocalTime(your_utc_time)). We could add a helper that does ('Zone.GetUtcOffsetAtUtc()' or something), but it's pretty easy to achieve without a helper anyway.

[pavkam]

ToLocalTime(TTimeZone.Local.ToUniversalTime(Now));

This is Delphi-specific AFAIK. I could add something like this if I can support both FPC and Delphi

[zedxxx]

This is Delphi-specific AFAIK. I could add something like this if I can support both FPC and Delphi

There is LocalTimeToUniversal available in FPC: https://www.freepascal.org/docs-html/rtl/dateutils/localtimetouniversal.html

Or, for Windows-only (Delphi and FPC), you can use:

function NowUTC: TDateTime;
var 
  UTC: TSystemTime;
begin
  GetSystemTime(UTC);
  Result := SystemTimeToDateTime(UTC);
end;

[pavkam]

Thanks @zedxxx, I will consider adding this when I get some free time