[jcifs] timezone problems

[Julian Reschke]

Julian Reschke wrote:

> Christopher R. Hertel wrote:
> ...
> Yes. But this shouldn't occur at that level. SmbFile is a filie I/O API, 
> not a user interface, and it's supposed to use UTC, not local time (at 
> least I would assume so because this is was java.io.File does).
> 
>> Does jCIFS return differnt values when running on, say, Linux vs. W2K 
>> and accessing the same file?
> 
> 
> I'll try tomorrow.

OK, here's (another) test scenario (jcifs 0.8.1b):

import java.io.File;
import java.io.IOException;
import java.util.Date;
import java.util.TimeZone;

import jcifs.smb.SmbFile;

public class TestTimeStamps {

	private static final long MS_PER_DAY = 60L * 60L * 24L * 1000L;
	
	static TimeZone TZ = TimeZone.getDefault();
	
	public static void main(String[] args) throws IOException {
		
		if (args.length != 2) {
			System.err.println("usage: TestTimeStamps smb-uri filename");
			System.exit(2);
		}
		
		System.out.println("== TIMEZONE INFO ==");
		System.out.println("Default TimeZone is: " + TZ);
		System.out.println();
		
		long ts = MS_PER_DAY * ((30 * 365) + 180); // date in summer
		
		System.out.println("== JAVA.IO.FILE INFO ==");
		
		File fsummer = new File(args[1] + "fsummer");
		fsummer.createNewFile();
		System.out.println("setting to: " + ts);
		fsummer.setLastModified(ts);
		long tsr = fsummer.lastModified();
		System.out.println("file summer lastmod: " + tsr + " " + tsr / 
MS_PER_DAY + " " + new Date(tsr));
		
		ts = MS_PER_DAY * (30 * 365);
		
		File fwinter = new File(args[1] + "fwinter");
		fwinter.createNewFile();
		System.out.println("setting to: " + ts);
		fwinter.setLastModified(ts);
		tsr = fwinter.lastModified();
		System.out.println("file winter lastmod: " + tsr + " " + tsr / 
MS_PER_DAY + " " + new Date(tsr));
		System.out.println();

		System.out.println("== JCIFS.SMB.SMMFILE INFO ==");
		
		SmbFile smbsummer = new SmbFile(args[0] + "fsummer");
		tsr = smbsummer.lastModified();
		System.out.println("smb summer lastmod: " + tsr + " " + tsr / 
MS_PER_DAY + " " + new Date(tsr));
		SmbFile smbwinter = new SmbFile(args[0] + "fwinter");
		tsr = smbwinter.lastModified();
		System.out.println("smb winter lastmod: " + tsr + " " + tsr / 
MS_PER_DAY + " " + new Date(tsr));
		
		System.out.println();
		
	}
}

Running this script on W2K and Linux yields the following results:


Host: Linux, Files on Linux (Samba): java.io.File and jcifs.smb.SmbFile 
yield consistente results

Host: W2K, File on W2K (Windows Networking): java.io.File returns 
consistent dates, but jcifs.smb.SmbFile breaks the timestampe for the 
"summer" file by substracting one hour

Host: W2K, File on Linux (Samba): java.io.File returns inconsistent 
dates (file in summer is 60 minutes ahead), but jcifs.smb.SmbFile dates 
are consistent

Note in both cases the Java VMs were using equivalent time zones.


Summary: both Samba and Jcifs seem to apply DST corrections. However 
Samba and Windows (2000 and 2003) do not behave consistently -- that is 
Samba itself doesn't seem to do the same thing as Windows, thus applying 
the very correction works with JCifs vs Samba, but not with JCifs vs 
Windows.

Thought: at this point, JCifs doesn't seem to work consistently with a 
Windows server. For me this *seems* to be caused by Samba not being 
fully compatible to W2000 as server, and JCifs compensating for Samba 
behaviour that the Windows servers I'm testing with do not expose.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760