Bug #99979 for Net-SFTP-Foreign: Returned remote mtime of same files changing after daylight saving time swap

Mon Nov 03 07:31:39 2014 acanfora [...] it.tiscali.com - Ticket created

Subject:	Returned remote mtime of same files changing after daylight saving time swap
Date:	Mon, 03 Nov 2014 13:31:15 +0100
To:	bug-Net-SFTP-Foreign [...] rt.cpan.org
From:	Anselmo Canfora <acanfora [...] it.tiscali.com>

Hi, I just noticed this bug that happens after Italian daylight saving time swap. The difference between old returned mtime and new one is exactly 3600, indicating that the server is sending and/or the library is parsing a time different from epoch. The remote sftp server specs are reported below: File transfer protocol = SFTP-3 Cryptographic protocol = SSH-2 SSH implementation = 5.1.3.8 SSH Tectia Server Encryption algorithm = aes Compression = No ------------------------------------------------------------ Server host key fingerprint ssh-rsa 1536 6d:6e:2f:9d:65:71:0b:15:1b:d8:14:b0:75:5b:fa:19 ------------------------------------------------------------ Can change permissions = Yes Can change owner/group = Yes Can execute arbitrary command = No Can create symlink/hardlink = Yes/No Can lookup user groups = No Can duplicate remote files = No Can check available space = No Can calculate file checksum = No Native text (ASCII) mode transfers = No ------------------------------------------------------------ Additional information The server supports these SFTP extensions: newline@vandyke.com="\r\n" Thank you in advance for the time you can devote to correct this. Anselmo Canfora

Mon Nov 03 09:35:13 2014 salva [...] cpan.org - Correspondence added

On Mon Nov 03 07:31:39 2014, acanfora@it.tiscali.com wrote: Show quoted text

> Hi, > I just noticed this bug that happens after Italian daylight saving time > swap. The difference between old returned mtime and new one is exactly > 3600, indicating that the server is sending and/or the library is > parsing a time different from epoch. The remote sftp server specs are > reported below: > > File transfer protocol = SFTP-3 > Cryptographic protocol = SSH-2 > SSH implementation = 5.1.3.8 SSH Tectia Server > Encryption algorithm = aes > Compression = No > ------------------------------------------------------------ > Server host key fingerprint > ssh-rsa 1536 6d:6e:2f:9d:65:71:0b:15:1b:d8:14:b0:75:5b:fa:19 > ------------------------------------------------------------ > Can change permissions = Yes > Can change owner/group = Yes > Can execute arbitrary command = No > Can create symlink/hardlink = Yes/No > Can lookup user groups = No > Can duplicate remote files = No > Can check available space = No > Can calculate file checksum = No > Native text (ASCII) mode transfers = No > ------------------------------------------------------------ > Additional information > The server supports these SFTP extensions: > newline@vandyke.com="\r\n" > > Thank you in advance for the time you can devote to correct this.

The protocol says that the server should return the timestamps in UTC: The `atime' and `mtime' contain the access and modification times of the files, respectively. They are represented as seconds from Jan 1, 1970 in UTC. There isn't much the client can do to correct it as the server doesn't tell the client its time configuration. Anyway, do you now which operating system does the remote system run?

Mon Nov 03 09:35:13 2014 The RT System itself - Status changed from 'new' to 'open'

Mon Nov 03 10:11:36 2014 acanfora [...] it.tiscali.com - Correspondence added

Subject:	Re: [rt.cpan.org #99979] Returned remote mtime of same files changing after daylight saving time swap
Date:	Mon, 03 Nov 2014 16:11:13 +0100
To:	bug-Net-SFTP-Foreign [...] rt.cpan.org
From:	Anselmo Canfora <acanfora [...] it.tiscali.com>

Hello sir, thank you very much for the prompt reply. We don't know yet what system they are running, we notified notified them about the anomaly just now. If the library takes the posix times as sent by server, without any interpretation, I think we can close this ticket as unconfirmed. I will nonetheless let you know about the server specs and operating system as soon as I know, for documentation purposes. Il 03/11/2014 15.35, Salvador Fandino Garcia via RT ha scritto: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=99979 > > > On Mon Nov 03 07:31:39 2014, acanfora@it.tiscali.com wrote:

>> Hi, >> I just noticed this bug that happens after Italian daylight saving time >> swap. The difference between old returned mtime and new one is exactly >> 3600, indicating that the server is sending and/or the library is >> parsing a time different from epoch. The remote sftp server specs are >> reported below: >> >> File transfer protocol = SFTP-3 >> Cryptographic protocol = SSH-2 >> SSH implementation = 5.1.3.8 SSH Tectia Server >> Encryption algorithm = aes >> Compression = No >> ------------------------------------------------------------ >> Server host key fingerprint >> ssh-rsa 1536 6d:6e:2f:9d:65:71:0b:15:1b:d8:14:b0:75:5b:fa:19 >> ------------------------------------------------------------ >> Can change permissions = Yes >> Can change owner/group = Yes >> Can execute arbitrary command = No >> Can create symlink/hardlink = Yes/No >> Can lookup user groups = No >> Can duplicate remote files = No >> Can check available space = No >> Can calculate file checksum = No >> Native text (ASCII) mode transfers = No >> ------------------------------------------------------------ >> Additional information >> The server supports these SFTP extensions: >> newline@vandyke.com="\r\n" >> >> Thank you in advance for the time you can devote to correct this.

> The protocol says that the server should return the timestamps in UTC: > > The `atime' and `mtime' contain the access and modification times of > the files, respectively. They are represented as seconds from Jan 1, > 1970 in UTC. > > There isn't much the client can do to correct it as the server doesn't tell the client its time configuration. > > Anyway, do you now which operating system does the remote system run? >

Wed Dec 03 06:43:15 2014 salva [...] cpan.org - Correspondence added

I am closing this bug as it is obviously a server side problem. In any case, I would really appreciate if you could tell me the vendor and version of the remote server so I can add a note about it into the bugs section.

Wed Dec 03 06:43:21 2014 salva [...] cpan.org - Status changed from 'open' to 'rejected'

Wed Dec 03 07:04:08 2014 ACANFORA [...] cpan.org - Correspondence added

Il Mer 03 Dic 2014 06:43:15, SALVA ha scritto: Show quoted text

> I am closing this bug as it is obviously a server side problem. > > In any case, I would really appreciate if you could tell me the vendor > and version of the remote server so I can add a note about it into the > bugs section.

Hello, here the server vendor and version: SSH Tectia Server 5.1.3.8 thank you for support!

Wed Dec 03 07:20:39 2014 salva [...] cpan.org - Correspondence added

On Wed Dec 03 07:04:08 2014, ACANFORA wrote: Show quoted text

> Il Mer 03 Dic 2014 06:43:15, SALVA ha scritto:

> > I am closing this bug as it is obviously a server side problem. > > > > In any case, I would really appreciate if you could tell me the vendor > > and version of the remote server so I can add a note about it into the > > bugs section.

> > > Hello, here the server vendor and version: > > SSH Tectia Server 5.1.3.8 > > thank you for support!

That's quite unexpected. Tectia is quite mature. Maybe the issue lies on the server operating system.