delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2013/01/29/03:55:29

X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO
X-Spam-Check-By: sourceware.org
Message-ID: <51078E6D.3090807@wmc.eu>
Date: Tue, 29 Jan 2013 09:55:09 +0100
From: Marten Jan de Ruiter <m DOT j DOT deruiter AT wmc DOT eu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Re: Intel FORTRAN time_and_date function returns UTC instead of local time
References: <51012EF9 DOT 805 AT aol DOT com>
In-Reply-To: <51012EF9.805@aol.com>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Op 24-1-2013 13:54, Tim Prince schreef:
> On 1/24/2013 5:01 AM, Marten Jan de Ruiter wrote:
>> I wrote a FORTRAN program using the time_and_date function. The 
>> source follows below. The time_and_date function returns the wrong 
>> time: I am not in UTC, so czone should be +0100.
>>
>> In the following output, the lines "ctime:..." to "milliseconds..." 
>> are based on time_and_date. The line 15:54:49 is the correct time 
>> obtained by the time function, and the line 23-JAN-13 is the correct 
>> date obtained by the date function.
>>
>> ctime: 20130123
>> cdate: 145449.947
>> czone: -0000
>> @ 2013-01-23 14:54:49.947
>>   year                 2013
>>   month                   1
>>   day                    23
>>   diff wrt UTC            0  minutes
>>   hours                  14
>>   minutes                54
>>   seconds                49
>>   milliseconds          947
>>
>>   15:54:49
>>   23-JAN-13
>>
>>
>> I have done some experiments to narrow down the problem:
>> * compiling with gfortran: time_gfortran.exe gives correct result in 
>> Cygwin
>> * compiling with g95: time_g95.exe gives the correct result in Cygwin
>> * compiling with ifort: time_ifort.exe gives the wrong time in Cygwin
>>
>> After copying cygwin1.dll, cyggfortran-3.dll and cyggcc_s-1.dll to 
>> the working directory, I get correct results
>> using the three executables in c:\windows\system32\cmd.exe.
>>
>> I suspect that the intel compiler does a different system call for 
>> time_and_date than for date and time, that the system call is 
>> intercepted by Cygwin, and not properly handled. I am still baffled 
>> why the same source runs fine for gfortran and g95. Notice however 
>> that for these compilers, the _date_ and _time_ functions are not 
>> defined. Hence the preprocessor exclusion in the source.
>>
>> Does anyone know how I can trace the system calls of my executables?
>>
>> Regards,
>>
>> Marten Jan
>>
>>
>>
>> The following example comes from the documentation of Intel:
>>
>> Consider the following
>> example executed on 2000 March 28 at 11:04:14.5:  INTEGER DATE_TIME 
>> (8)  CHARACTER (LEN = 12) REAL_CLOCK (3)  CALL DATE_AND_TIME 
>> (REAL_CLOCK (1), REAL_CLOCK (2), &                      REAL_CLOCK 
>> (3), DATE_TIME)
>> This assigns the value
>> "20000328" to REAL_CLOCK (1), the value "110414.500" to REAL_CLOCK 
>> (2), and the
>> value "-0500" to REAL_CLOCK (3). The following values are assigned to 
>> DATE_TIME:
>> 2000, 3, 28, -300, 11, 4, 14, and 500.
>>
>>
>> The following is the source of my program:
>>
>> program time_and_date
>>
>> implicit none
>>
>> character (len=8)  cdate
>> character (len=10) ctime
>> character (len=5) czone
>> integer(4) ival(8)
>> integer(4) yr,mon,day,hr,min,sec,ms
>>
>> call date_and_time(cdate,ctime,czone,ival)
>>
>> read (cdate(1:4),*) yr
>> read (cdate(5:6),*) mon
>> read (cdate(7:8),*) day
>> read (ctime(1:2),*) hr
>> read (ctime(3:4),*) min
>> read (ctime(5:6),*) sec
>> read (ctime(8:10),*) ms
>> print *,'cdate        ',cdate
>> print *,'ctime        ',ctime
>> print *,'czone        ',czone
>> print "('@ ',i4,'-',i2.2,'-',i2.2,' 
>> ',i2.2,':',i2.2,':',i2.2,'.',i3.3)", yr,mon,day,hr,min,sec,ms
>> print *,'year         ',ival(1)
>> print *,'month        ',ival(2)
>> print *,'day          ',ival(3)
>> print *,'diff wrt UTC ',ival(4),' minutes'
>> print *,'hours        ',ival(5)
>> print *,'minutes      ',ival(6)
>> print *,'seconds      ',ival(7)
>> print *,'milliseconds ',ival(8)
>> print *
>>
>> #ifdef IFORT
>>    call time(ctime)
>>    print *,ctime
>>
>>    call date(ctime)
>>    print *,ctime
>> #endif
>>
>> print *,'done'
>>
>> end program
>>
>>
>>
> For what little it's worth, the documentation of the ifort legacy 
> time() and date() functions states that they aren't reliable for dates 
> beyond year 1999 and the Fortran standard date_and_time should be 
> used.  There is no documented time_and_date().  As others hinted, 
> ifort bypasses cygwin .dll entirely, so the question has no 
> relationship to cygwin, although it could be related to your calendar 
> clock settings and the way Windows date setting is incompatible with 
> practices accepted outside Windows.
> -- Tim Prince
Thanks, it is an inconsistency in my program naming. Since I actually 
use the Fortran standard date_and_time(), this is not the issue. The 
notable thing is that the legacy time() and date() work properly in the 
cygwin environment. Since those calls do not work in g95 and gfortran, I 
can not use those calls. As a work-around, I could use date_and_time() 
for the c95 and gfortran compiler, and date() and time() for the ifort 
compiler, using the preprocesser to select the proper routines.

I still do not understand why time_ifort.exe works properly in the cmd 
environment, and why only its call to date_and_time() does not work 
properly in the cygwin environment.

I could not find anything in the mailing list for date_and_time, but 
I'll look further into ifort and cygwin.dll.

Thanks for the effort,

Marten Jan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019