You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have built a file synchronization service where we rely on the timestamps of files that we save in a DB.
We use SFTPClient.LastWriteTimeUtc to persist the date and time.
After Sweden changed to summertime, we experienced that files where considered as changed because they had a new time when calling SFTPFile.LastWriteTimeUtc. Files that had persisted 2012-12-01T11:51Z now got 2012-12-01T12:51Z.
It might be a problem with the server, CoreFTP, but I found a potential issue in SSH.NET code as well.
According to the RFC, the times here are unix timestamp, in UTC. These are decoded directly into DateTimes with DateTimeKind.Local in the code above. The accessTime and modifyTime should be in local time, as I understand code elsewhere
According to this article this is how that should be done properly:
publicstaticDateTimeUnixTimeStampToDateTime(doubleunixTimeStamp){// Unix timestamp is seconds past epochSystem.DateTimedtDateTime=newDateTime(1970,1,1,0,0,0,0,System.DateTimeKind.Utc);dtDateTime=dtDateTime.AddSeconds(unixTimeStamp).ToLocalTime();returndtDateTime;}
Note that it creates a DateTime with DateTimeKind.Utc first and then converts that to local time.
This difference might be the cause of my problems.
The article also mentions DateTimeOffset.FromUnixTimeMilliSeconds (source) which can be used together with DateTimeOffset.UtcdateTime to parse these dates.
I also had a look in the ScpClient.NET.cs where I found this code:
We have built a file synchronization service where we rely on the timestamps of files that we save in a DB.
We use SFTPClient.LastWriteTimeUtc to persist the date and time.
After Sweden changed to summertime, we experienced that files where considered as changed because they had a new time when calling SFTPFile.LastWriteTimeUtc. Files that had persisted
2012-12-01T11:51Z
now got2012-12-01T12:51Z
.It might be a problem with the server, CoreFTP, but I found a potential issue in SSH.NET code as well.
A look in https://github.com/sshnet/SSH.NET/blob/develop/src/Renci.SshNet/Sftp/SftpFileAttributes.cs:
According to the RFC, the times here are unix timestamp, in UTC. These are decoded directly into DateTimes with DateTimeKind.Local in the code above. The
accessTime
andmodifyTime
should be in local time, as I understand code elsewhereAccording to this article this is how that should be done properly:
Note that it creates a DateTime with DateTimeKind.Utc first and then converts that to local time.
This difference might be the cause of my problems.
The article also mentions
DateTimeOffset.FromUnixTimeMilliSeconds
(source) which can be used together withDateTimeOffset.UtcdateTime
to parse these dates.I also had a look in the ScpClient.NET.cs where I found this code:
In this case, the times are represented as UTC and this should be correct, I think.
The text was updated successfully, but these errors were encountered: