Timezone problem when displaying files on an ftp server?
Moderators: fgagnon, nikos, Site Mods
-
dft1
- Member

- Posts: 41
- Joined: 2002 Jul 30, 14:13
- Location: Atlanta GA US
Timezone problem when displaying files on an ftp server?
When I use x2 (0.0.0.59) to display a folder on my ISP's ftp server, all of the file modified time stamps appear to be 4 hours earlier from what Windows Explorer and Filezilla show. When I copy the file to a local drive, the confirm file replace dialog shows the unadjusted modified date (i.e. the date/time that Explorer/Filezilla displays). Once the file is copied to the local drive, the modified date is the unadjusted date, which matches the result of copying a file with Explorer/Filezilla.
My timezone settings is GMT - 5 with daylight savings adjustment (currently GMT -4).
For a file on the ftp server (located locally), modified date is:
4/26/04 10:36 AM in Explorer and Filezilla
4/26/04 6:36 AM in x2
After copying to local drive via x2, the file modified date is:
4/26/04 10:36 AM in Explorer, Filezilla, x2.
This is the same as when copying the file using Explorer.
Conclusion: x2 should not adjust for the local time zone when displaying files on an FTP server.
Does anybody else see it this way?
My timezone settings is GMT - 5 with daylight savings adjustment (currently GMT -4).
For a file on the ftp server (located locally), modified date is:
4/26/04 10:36 AM in Explorer and Filezilla
4/26/04 6:36 AM in x2
After copying to local drive via x2, the file modified date is:
4/26/04 10:36 AM in Explorer, Filezilla, x2.
This is the same as when copying the file using Explorer.
Conclusion: x2 should not adjust for the local time zone when displaying files on an FTP server.
Does anybody else see it this way?
-
nikos
- Site Admin

- Posts: 16344
- Joined: 2002 Feb 07, 15:57
- Location: UK
i hate to pass the bucket like that but it is all IE's fault
all timestamp information is meant to be in "universal" units unaffected from timezones or DST. It would seem that the times reported by FTP are already adjusted, so when x2 adds its adjustment they go 4 hours earlier
have you tried browsing FTP while in list mode? (i.e. not in detailed view). What times are reported on the statusbar then? Is there the same offset?
all timestamp information is meant to be in "universal" units unaffected from timezones or DST. It would seem that the times reported by FTP are already adjusted, so when x2 adds its adjustment they go 4 hours earlier
have you tried browsing FTP while in list mode? (i.e. not in detailed view). What times are reported on the statusbar then? Is there the same offset?
-
fgagnon
- Site Admin

- Posts: 3737
- Joined: 2003 Sep 08, 19:56
- Location: Springfield
I have similar erratic experience with the decidedly still "alpha" status of ftp hitched to x2.
(see parallel post)
The good news is that x2 can ftp well enough, often enough that I can get by without having to drag out a separate ftp-engine every time I need to make an ftp connection.
The good news is that x2 can ftp well enough, often enough that I can get by without having to drag out a separate ftp-engine every time I need to make an ftp connection.
-
dft1
- Member

- Posts: 41
- Joined: 2002 Jul 30, 14:13
- Location: Atlanta GA US
-
nikos
- Site Admin

- Posts: 16344
- Joined: 2002 Feb 07, 15:57
- Location: UK
-
fgagnon
- Site Admin

- Posts: 3737
- Joined: 2003 Sep 08, 19:56
- Location: Springfield
I can't speak for dft1, but I get paranormal dating behaviour, nikos.
sometimes +4Hrs error, sometimes -4Hrs in same folder; sometimes correcting to 0 Hrs delta after return to ftp-site making no changes all within latest x2 & starting in list mode.
I should try IE's ftp by itself & compare.
... also a clean dbmon spew, if you think it might help.
(But I thought this was OT for getting a beta release, so I don't know how much I want to feed you if it would delay that effort.)
sometimes +4Hrs error, sometimes -4Hrs in same folder; sometimes correcting to 0 Hrs delta after return to ftp-site making no changes all within latest x2 & starting in list mode.
I should try IE's ftp by itself & compare.
... also a clean dbmon spew, if you think it might help.
(But I thought this was OT for getting a beta release, so I don't know how much I want to feed you if it would delay that effort.)
-
nikos
- Site Admin

- Posts: 16344
- Joined: 2002 Feb 07, 15:57
- Location: UK
-
nikos
- Site Admin

- Posts: 16344
- Joined: 2002 Feb 07, 15:57
- Location: UK
-
fgagnon
- Site Admin

- Posts: 3737
- Joined: 2003 Sep 08, 19:56
- Location: Springfield
I usually don't, but I did, so I turned it off & it didn't make any difference.
[EDIT: it's easier to see it than explain it. & you saw it while I was trying to explain it in writing & misssed your post until after & finished, ho-hum
:end EDIT]
but here's what I found comparing 3 ftp tools (x2ftp, IEftp, WSFTP):
First (as reported in a parallel thread) there is a refresh problem with x2's ftp (the others have an explicit refresh command). That prevents x2 from seeing updates to ftp-site without a restart.
Using any of the other tools, to report uploads to my ISP's ftp-site, the "modified" time reported is correct if taken as being GMT -- as is the report with x2's ftp after restart.
Using WSFTP, the time shown with the date is immediately displayed in GMT for files uploaded with WSFTP (or with the others).
Using IE ftp feature, the time shown is immediately displayed in local time for files uploaded with IE ftp -- but after refresh, the same files are shown with "modifed" time consistent with GMT at time of upload.
{This shift contributes to paranormal behaviour}
Using x2 ftp, files it uploads "modified" time shows immediately as localtime plus the GMT offset, effectively doubling it (at first). [edit: correction to dyslectic math signing in prior line]
After refresh by stop/restart, they show as correct local time modified.
So you're at least half-right -- there is aproblem with IE.
But there is also a problem in that the local time is not the time posted as "modified" for this ftp site. I suspect this situation may vary from site to site, depending on how carefully the admin has configured the time options.
Maybe if you extend the x2 refresh to RELIABLY poll IE's View | Refresh, you can get the two to behave the same. I don't know what you can do about site-specific time policy (or lack thereof) -- or whether there are generally accepted standards that are observed in practice.
[EDIT: it's easier to see it than explain it. & you saw it while I was trying to explain it in writing & misssed your post until after & finished, ho-hum
but here's what I found comparing 3 ftp tools (x2ftp, IEftp, WSFTP):
First (as reported in a parallel thread) there is a refresh problem with x2's ftp (the others have an explicit refresh command). That prevents x2 from seeing updates to ftp-site without a restart.
Using any of the other tools, to report uploads to my ISP's ftp-site, the "modified" time reported is correct if taken as being GMT -- as is the report with x2's ftp after restart.
Using WSFTP, the time shown with the date is immediately displayed in GMT for files uploaded with WSFTP (or with the others).
Using IE ftp feature, the time shown is immediately displayed in local time for files uploaded with IE ftp -- but after refresh, the same files are shown with "modifed" time consistent with GMT at time of upload.
{This shift contributes to paranormal behaviour}
Using x2 ftp, files it uploads "modified" time shows immediately as localtime plus the GMT offset, effectively doubling it (at first). [edit: correction to dyslectic math signing in prior line]
After refresh by stop/restart, they show as correct local time modified.
So you're at least half-right -- there is aproblem with IE.
But there is also a problem in that the local time is not the time posted as "modified" for this ftp site. I suspect this situation may vary from site to site, depending on how carefully the admin has configured the time options.
Maybe if you extend the x2 refresh to RELIABLY poll IE's View | Refresh, you can get the two to behave the same. I don't know what you can do about site-specific time policy (or lack thereof) -- or whether there are generally accepted standards that are observed in practice.
-
nikos
- Site Admin

- Posts: 16344
- Joined: 2002 Feb 07, 15:57
- Location: UK
-
dft1
- Member

- Posts: 41
- Joined: 2002 Jul 30, 14:13
- Location: Atlanta GA US
-
nikos
- Site Admin

- Posts: 16344
- Joined: 2002 Feb 07, 15:57
- Location: UK
-
ByteRisc
- Member

- Posts: 10
- Joined: 2004 Oct 01, 20:15
I had the same difficulties with file mtime using Perl and Net::FTP.
The problem comes in that FTP returns file stats in gmtime. and local time is, well local. So if you use the gmtime function (which converts the seconds since the epoch to local time for you). You will have better success.
Can you use gmtime with ftp protocols, and local time with everything else?
The problem comes in that FTP returns file stats in gmtime. and local time is, well local. So if you use the gmtime function (which converts the seconds since the epoch to local time for you). You will have better success.
Can you use gmtime with ftp protocols, and local time with everything else?
-
ByteRisc
- Member

- Posts: 10
- Joined: 2004 Oct 01, 20:15
-
patlange
- Member

- Posts: 56
- Joined: 2004 Oct 19, 23:38
- Location: Rochester, New York