For Programmers: Free Programming Magazines  


Home > Archive > Fortran > September 2006 > convert epoch time to yyyymmdd hhmmss









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author convert epoch time to yyyymmdd hhmmss
beliavsky@aol.com

2006-09-19, 7:02 pm

The fstat function, implemented in some Fortran compilers, returns,
among other things, the time a file was last modified, in seconds after
midnight, 1970. Does anyone have Fortran code to convert this to a date
and time in yyyymmdd hhmmss format?

glen herrmannsfeldt

2006-09-19, 7:02 pm

beliavsky@aol.com wrote:
> The fstat function, implemented in some Fortran compilers, returns,
> among other things, the time a file was last modified, in seconds after
> midnight, 1970. Does anyone have Fortran code to convert this to a date
> and time in yyyymmdd hhmmss format?


For unix, which is where the midnight 1970 epoch comes from,
and where fstat() is a unix (manual section 2) library function,
there is localtime() and ctime().

Local time fills in a structure containing year, month, day,
hour, minute, and seconds and integers.

ctime returns a static pointer to a character string version
of the year, month, day, hour, minute, and seconds.

Your library might also have Fortran callable versions of
localtime or ctime.

-- glen

Walter Spector

2006-09-19, 10:01 pm

beliavsky@aol.com wrote:
>
> The fstat function, implemented in some Fortran compilers, returns,
> among other things, the time a file was last modified, in seconds after
> midnight, 1970. Does anyone have Fortran code to convert this to a date
> and time in yyyymmdd hhmmss format?


If your compilation environment supports the POSIX routines, (Intel, for one),
you can simply call PXFLOCALTIME to do this:

call PXFLOCALTIME (isecnds, iatime, ierror)

where

isecnds - input integer with # of seconds since jan 1, 1970

iatime - output array returning the following:

1 - seconds (0 - 61, for leap seconds)
2 - minutes (0 - 59)
3 - hours (0 - 23)
4 - day of the month (1 - 31)
5 - month of the year (1 - 12)
6 - Gregorian year (e.g., 2006)
7 - Day of the w (0 = sunday)
8 - Day of the year (1 - 366)
9 - DST flag (0 = standard, 1 = DST)

ierror - Returns 0 if successful, EINVAL if not.

Note that by the POSIX Standard, some of the return values are '1-based'
in Fortran, whereas the C 'localtime' counterpart returns '0-based' values.
(Off the top of my head, day of the year is one of them.)

Hope this helps,

Walt
Ben Hetland

2006-09-20, 8:01 am

Walter Spector wrote:
> Note that by the POSIX Standard, some of the return values are '1-based'
> in Fortran, whereas the C 'localtime' counterpart returns '0-based' values.
> (Off the top of my head, day of the year is one of them.)


According to the documentation for my compiler, the PXFLOCALTIME returns
values in the expected ranges (i.e. hh:mm:ss all 0-based, as well as day
of the w, all others 1-based). One less confusion IMO...

If I look up the corresponding routines in the C library, they are
different in the following:

month of the year (0 - 11)
Gregorian year (years since 1900)

so [year=102, month=10, day=3] would mean 2002-11-03.

OP asked for source that did this. If that is still important, one
possibility would be to look up GNU's implementation of the gmtime()
function (if only UTC times is of importance), or the more complex
localtime() which would be the equivalent to PXFLOCALTIME I presume.
Although that code is written in C, these are mostly elementary
calculation formulas that are easily converted into Fortran syntax.
--
-+-Ben-+-
David Flower

2006-09-20, 8:01 am


beliavsky@aol.com wrote:
> The fstat function, implemented in some Fortran compilers, returns,
> among other things, the time a file was last modified, in seconds after
> midnight, 1970. Does anyone have Fortran code to convert this to a date
> and time in yyyymmdd hhmmss format?


I wonder if it contains the Y2100 bug.

(2100 will not be a leap year).

Dave Flower

PS My version of Excel (2002) knows that 2100 is not a leap year, but
thinks that 1900 was!

Klaus Wacker

2006-09-20, 8:01 am

beliavsky@aol.com wrote:
> The fstat function, implemented in some Fortran compilers, returns,
> among other things, the time a file was last modified, in seconds after
> midnight, 1970. Does anyone have Fortran code to convert this to a date
> and time in yyyymmdd hhmmss format?
>


I don't know of ready-made fortran code for the complete task, but the
yyyymmdd part, which is the hard part, can be done with the help of
the datesub package of H. D. Knoble, posted here a while ago. A quick
google search shows e.g.
http://ftp.cac.psu.edu/pub/ger/fortran/hdk/datesub.for

--
Klaus Wacker wacker@Physik.Uni-Dortmund.DE
Experimentelle Physik V http://www.physik.uni-dortmund.de/~wacker
Universitaet Dortmund Tel.: +49 231 755 3587
D-44221 Dortmund Fax: +49 231 755 4547
Herman D. Knoble

2006-09-20, 7:01 pm

The following code will yield the file's date.
Skip Knoble

! This file: fs.f90
! Example using CVF.
INTEGER :: FESULT, FSTAT,LUNIT,STATB(10), D, YYYY,MM,DD
OPEN(50,file="fs.f90")
result = FSTAT (50, statb)
print *, "STATB(10)=",STATB(10)
D = statb(10)/(24*60*60)
print *, "D=",D
call CDATE(2440588 + D,YYYY,MM,DD)
print *, "File Date =",YYYY,MM,DD
end

SUBROUTINE CDATE(JD,YYYY,MM,DD)
!=====GIVEN A JULIAN DAY NUMBER, NNNNNNNN, YYYY,MM,DD ARE RETURNED AS
! AS THE CALENDAR DATE. JD=NNNNNNNN IS THE JULIAN DATE
! FROM AN EPOCK IN THE VERY DISTANT PAST. SEE CACM
! 1968 11(10):657, LETTER TO THE EDITOR BY FLIEGEL AND
! VAN FLANDERN.
! EXAMPLE CALL CDATE(2440588,YYYY,MM,DD) RETURNS 1970 1 1 .
!
INTEGER :: JD,YYYY,MM,DD,L,N
L=JD+68569
N=4*L/146097
L=L-(146097*N + 3)/4
YYYY=4000*(L+1)/1461001
L=L-1461*YYYY/4+31
MM=80*L/2447
DD=L-2447*MM/80
L=MM/11
MM=MM + 2 - 12*L
YYYY=100*(N-49) + YYYY + L
RETURN
END


On 19 Sep 2006 16:06:51 -0700, beliavsky@aol.com wrote:

-|The fstat function, implemented in some Fortran compilers, returns,
-|among other things, the time a file was last modified, in seconds after
-|midnight, 1970. Does anyone have Fortran code to convert this to a date
-|and time in yyyymmdd hhmmss format?

glen herrmannsfeldt

2006-09-20, 7:01 pm

Walter Spector <w6ws_xthisoutx@earthlink.net> wrote:
> beliavsky@aol.com wrote:


[color=darkred]
> If your compilation environment supports the POSIX routines,
> (Intel, for one), you can simply call PXFLOCALTIME to do this:


> call PXFLOCALTIME (isecnds, iatime, ierror)


In that case, there should have been PXFSTAT() or PXFFSTAT()
instead of fstat().

Though fstat() is a little strange. In unix, fstat() uses a unix-style
file descriptor where stat() expects a file name. It would be nice
to have one using a Fortran unit number. As far as I know, PXFFSTAT
expects a unix (or presumably POSIX) file descriptor.

-- glen
glen herrmannsfeldt

2006-09-20, 7:01 pm

David Flower <DavJFlower@aol.com> wrote:

> beliavsky@aol.com wrote:
[color=darkred]
> I wonder if it contains the Y2100 bug.


> (2100 will not be a leap year).


More usual is the 2038 bug.

Seconds since 1970 overflows a 32 bit integer in 2038.

A little longer if unsigned, but usually it isn't.

It seems to be documented in http://www.2038bug.com

-- glen
Walter Spector

2006-09-20, 7:01 pm

glen herrmannsfeldt wrote:
>
> Walter Spector <w6ws_xthisoutx@earthlink.net> wrote:
> ...
>
>
> In that case, there should have been PXFSTAT() or PXFFSTAT()
> instead of fstat().


And in fact, both are in the PXF Standard.

> Though fstat() is a little strange. In unix, fstat() uses a unix-style
> file descriptor where stat() expects a file name. It would be nice
> to have one using a Fortran unit number. As far as I know, PXFFSTAT
> expects a unix (or presumably POSIX) file descriptor.


This is true. One can obtain the file descriptor associated with a unit
number by using PXFFILENO:

call PXFFILENO (iunit, ifildes, ierror)

Where:

iunit - Fortran unit number (input)

ifildes - Returns the associated POSIX file descriptor

ierror - 0 if successful, errno if an error occurs

Walt
Jan Vorbrüggen

2006-09-21, 4:01 am

> More usual is the 2038 bug.
>
> Seconds since 1970 overflows a 32 bit integer in 2038.


Yes, I am counting on augmenting my retirement income by helping people
to cope with it.

> A little longer if unsigned, but usually it isn't.


Well, "a little longer" means another 68+ years, i.e., until 2106. I don't
really expect to be around at that time, which is just as well - fixing the
2038 bug means fixing the code in an obvious way (treat the data as unsigned
instead of signed), while in 2106 one has a data representation problem that's
much harder to correct.

Jan
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com