MDTM

[goodeye]

Hi again,

I am getting different behavior with local vs server timestamps, related to time zones. I pinned this down to MDTM again.
BC3 v3.1.2 build 10221
Titan FTP Server v7.02 Pro

Short story: When using MDTM to set the remote timestamp, BC3 is "double adjusting" for the time zone, setting the remote file ahead too far. MFMT is behaving correctly.

Using MDTM to set remote timestamps is technically improper, but common, so I again appreciate that you support it. So, pending Titan fixing their MFMT, you're welcome to fix or drop this issue with MDTM.

Details (probably overkill):

BC3 and the Server are both in Pacific Daylight Time, both set to -8 with DST = -7; depending how you look at it. This issue is about the 7 hour difference; the daylight saving 1 hour is behaving correctly (i.e., this is not a daylight saving issue)

Transferring a file, and touching the remote file, both have the same behavior, so we don't have to distinguish that here.

Local file:
asdf.txt modify time is May 3, 2009 9:10:14 am PDT.
In UTC, it's +7 from this: 20090503161014
(windows isn't showing the fractions of seconds to me)

When MFMT is enabled, it sends the correct UTC time: 20090503161014.477
When forcing it to use MDTM, it adds 14 hours, and sends 20090503231014.477

Thanks as always,
Bob

[Zoë]

Hi Bob,

I think we'll just leave this as fixed in the next release by fixing the incompatibility with MFMT.

Like you said, MDTM is non-standard, and one of those issues is whether the timestamp passed should be in local time or UTC. Some servers expect it one way and some the other. BC uses the format of the command as listed in the FEAT response to guess which way it should send it. Titan used to require local time and switched to UTC later. Since they now support MFMT I don't see much reason to change the current behavior and potentially break other servers.