JDK-4242143 : java.io.File.lastModified incorrect during daylight savings (win32)
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.2.0,1.2.1,1.2.2
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_95,windows_nt
  • CPU: x86
  • Submitted: 1999-05-28
  • Updated: 2001-10-12
  • Resolved: 2000-03-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.0 betaFixed
Related Reports
Relates :  
Description

Name: krT82822			Date: 05/27/99


If Windows' date/time control panel's "Automatically adjust clock for daylight savings changes" is on, there is a one-hour discrepancy between
the last-modified time shown by the Win/DOS "dir" command (for a file created during STANDARD time) and the last-modified time returned
by File.lastModified() (when the current date falls during Daylight Savings Time).

This means that Bug 4077832 appears to still exist in JDK 1.2.1, though it was nominally fixed for JDK 1.2beta4 (fixed unverified).

------------------------------

User description:

Some simple test source (WIN/95) and a file with a date
stamp of Sun Feb 28 10:49:44 PST 1999

import java.awt.*;
import java.applet.*;
import java.io.*;
import java.lang.*;
import java.net.*;
import java.util.Date;

public class T
{
     public static void main (String[] argv) {
            System.out.println("Runnin T, If JVM 1.2 the timestamp is wrong");
            File tmp = new File("crome.sup");
            if (tmp.exists()) {
                    Date d = new Date(tmp.lastModified()) ;
                System.out.println( d + " - or - " + d.toGMTString());
            } else {
                System.out.println( "error no file crome.sup" );
            }
     }

}

DIR CROME.SUP

 Volume in drive C has no label
 Volume Serial Number is 1B6A-14E9
 Directory of C:\WebApps\Crome

CROME    SUP        58,844  02-28-99 10:49a crome.sup
         1 file(s)         58,844 bytes
         0 dir(s)        3,447.53 MB free


Now run under different VMs note the incorrect offset of
the file lastModified under 1.2.1

java version "1.1.7B"
Runnin T, If JVM 1.2 the timestamp is wrong
Sun Feb 28 10:49:44 PST 1999 - or - 28 Feb 1999 18:49:44 GMT

java version "1.2.1"
HotSpot VM (1.0fcs, mixed mode, build E)
Runnin T, If JVM 1.2 the timestamp is wrong
Sun Feb 28 09:49:44 PST 1999 - or - 28 Feb 1999 17:49:44 GMT
(Review ID: 83597) 
======================================================================

Name: krT82822			Date: 05/27/99


In WinNt user have an option of turning Daylight Saving Time (DST) on and off, in JAVA it always on.

To reproduce the problem:
1. Start Date/Time Properties dialog
2. Set time to 1:56 a.m. and date to the first sunday of april of any year
(April 4 1999)
3. Uncheck "Automatically adjust click for DST" in Time Zone page and press
Apply/OK


4. 
    while(1)
    {
      try{
       System.out.println(new Date().toString());
       Sleep(60*2000);
      }catch(Exception e){}
    } 
 
You will see the timestamp like 1999/04/04 01:58:35 EST

5. In 2 min the timestamp will be 1999/04/04 03:00:35 EDT. When NT clock shows that time is 02:00:35 EST
(Review ID: 83559)
======================================================================

Name: rlT66838			Date: 11/04/99


java full version "JDK-1.2.2-001"

This is exactly the same problem as described in bug number 4077832,
except that my platform is Windows 95, and the problem has not been fixed.

  To recap: the result of java.io.File.lastModified() gives different
results for the same file (untouched between runs) before and after
a Daylight Savings switchover.

I first ran across the problem on a "1.2-V" installation.
Since the original defect report claimed to have fixed this
(for NT at least) in 1.2beta4, I tried upgrading to today's
latest (1.2.2-001).  Still broken (on W95).
(Review ID: 97498)
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic merlin-beta FIXED IN: merlin-beta INTEGRATED IN: merlin-beta VERIFIED IN: merlin-beta3
14-06-2004

WORK AROUND Name: krT82822 Date: 05/27/99 User workarounds: None, do not use 1.2.1 on WIn95/98 Note 1.2-V on Solaris is fine ----------------- (kevin.ryan@eng -- turn off "Automatically adjust clock for daylight saving changes" in Win date/time control panel) ======================================================================
11-06-2004

EVALUATION A fix for winNT is known but the fix is not appropriate for win95/98. michael.mccloskey@eng 1999-09-24 We will add the fix for NT in the merlin release. michael.mccloskey@eng 2000-02-03 The NT fix has been putback for this bug. There can still be one hour discrepancies on win95, which handles the file times differently than winNT does. When using samba there may be 1 hour offsets that we cannot avoid. File times over NFS appear to be unaffected by the DST shifts. winNT results: File created in: PST PDT local: PST ok PDT ok PST ok PDT ok NFS: PST ok PDT ok PST ok PDT ok samba: PST ok PDT -1hr PST +1hr PDT ok win95/98 results: File created in: PST PDT local: PST ok PDT -1hr PST ok PDT -1hr NFS: PST ok PDT ok PST ok PDT ok samba: PST ok PDT -1hr PST +1hr PDT ok This bug is due to the way that the win platform changes file times when the "Automatically adjust for daylight savings" is turned on. It is difficult to work around because the file time may or may not have been changed depending upon the OS settings and the origin of the file. michael.mccloskey@eng 2000-02-24
24-02-2000