Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timezone conversion issue - Version 33.x #656

Closed
sierrodc opened this issue Dec 1, 2020 · 5 comments
Closed

Timezone conversion issue - Version 33.x #656

sierrodc opened this issue Dec 1, 2020 · 5 comments

Comments

@sierrodc
Copy link

sierrodc commented Dec 1, 2020

FTP OS: Windows

Computer OS: Windows 10

FluentFTP Version: 33.04

Hi,
According to the documentation, version 33.x introduced a new way to consider timezones. According to the code in FtpClient_Timezone.cs file, the code (at least for CORE) is:

if (m_timeConversion == FtpDate.LocalTime) {
    date = date + m_localTimeOffset;
}

where m_localTimeOffset is (not sure) the offset specified in the FtpClient.LocalTimeZone property.
But, m_localTimeOffset should be different in case of summer-winter time, so, it depends on the date that is going to be converted itself.

In my opinion, the code used for .net framework (that is, date = System.TimeZone.CurrentTimeZone.ToLocalTime(date);) should be also applied in CORE.

For the moment, I rolled back to version 32.x.

@robinrodricks
Copy link
Owner

.NET core was coded differently because it did not support the same methods as .NET Framework.

@sierrodc
Copy link
Author

sierrodc commented Dec 6, 2020

You are right. System.TimeZone is marked as "Obsolete" in .net standard 2.x and not even available in .net standard 1.x.

However is it possible to rewrite everything using System.TimeZoneInfo (any .net standard):

date = TimeZoneInfo.ConvertTime(date, TimeZoneInfo.Local);

But, I don't know if the timestamp sent by the server is always UTC or not. Otherwise a workaround is to allow user to inject a "IConvertTimestamp" object or just a Func<DateTime, DateTime> to handle the conversion manually. Otherwise, I can (in my code) remove 1h, and convert it later. Just hypothesis.

What I know is that:
2020-01-01 00:00:00 (UTC) should be converted to 2020-01-01 01:00:00 (CET)
2020-06-01 00:00:00 (UTC) should be converted to 2020-06-01 02:00:00 (CET)

@robinrodricks
Copy link
Owner

If you can suggest some part of the API to change, it can be done.

@robinrodricks
Copy link
Owner

Added to the bucket list. We will pick this up as and when we have free time. Comment on this issue if you want us to prioritize it. Thanks!

@robinrodricks robinrodricks closed this as not planned Won't fix, can't repro, duplicate, stale Sep 19, 2022
@robinrodricks
Copy link
Owner

However is it possible to rewrite everything using System.TimeZoneInfo (any .net standard):

Done!

See #1680 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants