DOS compressed date/time into real date/time 
Author Message
 DOS compressed date/time into real date/time

  Hi

  One of numerous Salford fortran tricks with OS files/directories
allows to find all attributes of files and directories. Unfortunately
file date and time grabbed in compressed format. It is needed
to convert decimal number to 16 bit binary and take specific bytes
out of it to find real date and time, WinAPI for example writes details
about this, not big deal, but I do not like loose time right now, may be later.

 Probably someone already did this exercise of coverting
DOS compressed date/time into real date/time of the file
and can share its Fortran source (any,  just for fun better F90/F95  :-)

 Thanks in advance.

---------



Wed, 18 Jun 1902 08:00:00 GMT  
 DOS compressed date/time into real date/time
[Is that a valid e-mail address?  It looks suspect, so I'm just posting
 instead of e-mailing.]

Quote:

>   One of numerous Salford Fortran tricks with OS files/directories
> allows to find all attributes of files and directories. Unfortunately
> file date and time grabbed in compressed format. It is needed
> to convert decimal number to 16 bit binary and take specific bytes
> out of it to find real date and time, WinAPI for example writes details
> about this, not big deal, but I do not like loose time right now, may be later.

>  Probably someone already did this exercise of coverting
> DOS compressed date/time into real date/time of the file
> and can share its Fortran source (any,  just for fun better F90/F95  :-)

Hope the bitfield formats here are correct for your purposes.  These
are the formats that Win32 uses for DosFileTime.  This is fixed-form
source, written for LF77/32EM (that's an intermediate between F77
and F90).  I'm not sure there would be any significant changes for a
pure F90 environment other than switching to free source form.

I use default INTEGERs for the bitfields; they need at least two bytes,
on the system I use they are four bytes and I ignore the high two
bytes.

--
Craig Powers


!===============================================================================!
      ! Function DecodeDateTime
      !
      ! Bitfield format:
      !    Date:   0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16
      !            +-day---+ +-mon-+ +-year---------------+ (year offset
from 1980)
      !    Time:   +-sec/2-+ +-minute---+ +-hour----------+ (values
count from 0)
      !
      ! Arguments:
      ! wPackedDate = Date bitfield.
      ! wPackedTime = Time bitfield.
      ! nYear, nMonth, nDay, nHour, nMinute, nSecond = decoded values
      !
      ! Returns:
      ! .TRUE. if successful, .FALSE. if data are invalid
      ! NOTE that the date is not checked for validity e.g. 31 days in
February
      ! even though it is checked for out-of-range values
      !

      LOGICAL FUNCTION DecodeDateTime(wPackedDate, wPackedTime,
     &        nYear, nMonth, nDay, nHour, nMinute, nSecond)

      IMPLICIT NONE

      INTEGER wPackedDate, wPackedTime
      INTEGER nYear, nMonth, nDay, nHour, nMinute, nSecond

      INTEGER nSecMask, nMinMask, nHrMask
      INTEGER nDayMask, nMonMask, nYrMask

      DATA nSecMask, nMinMask, nHrMask /Z'1F', Z'3F', Z'1F'/
      DATA nDayMask, nMonMask, nYrMask /Z'1F', Z'0F', Z'7F'/

      DecodeDateTime = .FALSE.

      ! Decode time
      nSecond = IAND(      wPackedTime,       nSecMask) * 2
      nMinute = IAND(ISHFT(wPackedTime,  -5), nMinMask)
      nHour =   IAND(ISHFT(wPackedTime, -11), nHrMask) ! Shouldn't need
the mask here

      IF (nSecond > 59) RETURN
      IF (nMinute > 59) RETURN
      IF (nHour > 23) RETURN

      ! Decode date
      nDay =   IAND(      wPackedDate,      nDayMask)
      nMonth = IAND(ISHFT(wPackedDate, -5), nMonMask)
      nYear =  IAND(ISHFT(wPackedDate, -9), nYrMask) + 1980

      IF (nDay == 0) RETURN
      IF (nMonth > 12) RETURN

      DecodeDateTime = .TRUE.

      RETURN
      END

!===============================================================================!
      ! Function EncodeDateTime
      !
      ! Bitfield format:
      !    Date:   0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16
      !            +-day---+ +-mon-+ +-year---------------+ (year offset
from 1980)
      !    Time:   +-sec/2-+ +-minute---+ +-hour----------+ (values
count from 0)
      !
      ! Arguments:
      ! wPackedDate = Date bitfield.
      ! wPackedTime = Time bitfield.
      ! nYear, nMonth, nDay, nHour, nMinute, nSecond = decoded values
      !
      ! Returns:
      ! .TRUE. if successful, .FALSE. if data are invalid
      ! NOTE that the date is not checked for validity e.g. 31 days in
February
      ! even though it is checked for out-of-range values
      !

      LOGICAL FUNCTION EncodeDateTime(wPackedDate, wPackedTime,
     &        nYear, nMonth, nDay, nHour, nMinute, nSecond)

      IMPLICIT NONE

      INTEGER wPackedDate, wPackedTime
      INTEGER nYear, nMonth, nDay, nHour, nMinute, nSecond

      EncodeDateTime = .FALSE.

      IF ( (nSecond  >= 60) .OR.
     &     (nMinute  >= 60) .OR.
     &       (nHour    >= 24) .OR.
     &       (nDay     >  31) .OR.
     &       (nMonth   >  12) .OR.
     &       (nYear    <   0)      ) RETURN

      wPackedDate = 0
      wPackedTime = 0

      wPackedTime = ISHFT(nHour, 6)
      wPackedTime = ISHFT(wPackedTime + nMinute, 5)
      wPackedTime = wPackedTime + nSecond / 2

      wPackedDate = ISHFT(nYear - 1980, 4)
      wPackedDate = ISHFT(wPackedDate + nMonth, 5)
      wPackedDate = wPackedDate + nDay

      EncodeDateTime = .TRUE.

      RETURN
      END



Wed, 18 Jun 1902 08:00:00 GMT  
 DOS compressed date/time into real date/time

Thanks Craig, this is exactly what I need.
Clearly written, well documented, looks nice.

Respect to F90/F95 I was just smiled.
Who knows, may be someone had written similar
things, say,  in ultimate ultracompact, a la James van Buskirk
(sorry, James, you named it) style which crashes
some compilers  ! This would be definitely acceptable now,
i.e. close to weekend time...  ;-)

----------



Wed, 18 Jun 1902 08:00:00 GMT  
 DOS compressed date/time into real date/time

Quote:

>      !    Date:   0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16
>      !            +-day---+ +-mon-+ +-year---------------+ (year offset
>from 1980)
>      !    Time:   +-sec/2-+ +-minute---+ +-hour----------+ (values
>count from 0)

Seven{*filter*} bit words?

Still, it works just fine if you only use up to bit 15 in each word.
But I thought Intel machines were little-endian.  Shouldn't these be
displayed in reverse order?

--
J. Giles



Wed, 18 Jun 1902 08:00:00 GMT  
 DOS compressed date/time into real date/time

Quote:


> >      !    Date:   0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16
> >      !            +-day---+ +-mon-+ +-year---------------+ (year offset
> >from 1980)
> >      !    Time:   +-sec/2-+ +-minute---+ +-hour----------+ (values
> >count from 0)

> Seven{*filter*} bit words?

> Still, it works just fine if you only use up to bit 15 in each word.
> But I thought Intel machines were little-endian.  Shouldn't these be
> displayed in reverse order?

> --
> J. Giles

But did you noticed something more important than just typo?

In 2045 date counter will start again from 1980!

Prepare to sue SomeOne for another short-minding,
the disaster of larger scale than Y2K which may blow up $'s.
Live long, keep your PCs in garage, and start to find your
lawer's now :-).

Good weekend,
and be happy
-------



Wed, 18 Jun 1902 08:00:00 GMT  
 DOS compressed date/time into real date/time

...

Quote:
>But did you noticed something more important than just typo?

>In 2045 date counter will start again from 1980!

Actually, even cutting the word back to 16 bits instead of the
displayed seven{*filter*} leaves 7 bits for the year.  That's 2^7,
or 128 years before the year coding cycles.  I'm hoping
no one will still be using DOS in 2108.

The UNIX people have a 32-bit counter for seconds that
goes negative in 2038.  That may be a problem :-(.

--
J. Giles



Wed, 18 Jun 1902 08:00:00 GMT  
 DOS compressed date/time into real date/time

Quote:


> ...
> >But did you noticed something more important than just typo?

> >In 2045 date counter will start again from 1980!

> Actually, even cutting the word back to 16 bits instead of the
> displayed seven{*filter*} leaves 7 bits for the year.  That's 2^7,
> or 128 years before the year coding cycles.

Ok, 2046, and hope that's deal.
Or I'll find a million others who want bug even earlier.
Tell your Ok and Bug Netnet-Giles Officially Named.
Let's not take hope from people anyway.
One problem, more companions needed.
Should we ask Gary to sponsor bug promotion ?

Quote:
> I'm hoping
> no one will still be using DOS in 2108.

No one already uses DOS but DOS file system is forever.
Think this way. Y2K was able to launch couple of mad
missiles and brake couple of banks. Netnet-Giles Bug
(whatever date) will be able to trigger the war between
future civilizations.

Quote:
> The UNIX people have a 32-bit counter for seconds that
> goes negative in 2038.  That may be a problem :-(.

I definitely have to tell something about UNIX  but not publicly.

---------



Wed, 18 Jun 1902 08:00:00 GMT  
 DOS compressed date/time into real date/time


[ snip ]

|> The UNIX people have a 32-bit counter for seconds that
|> goes negative in 2038.  That may be a problem :-(.

Only for Unixes with a 32-bit time_t.  UNICOS, for example, has a 64-bit
time_t and is good for another ~290 billion years which should be well
beyond the operational life of any Unix-based system, if not the universe.  ;-)


--
Matter: A degenerate, sticky substance which condenses out of low-energy
quarks.  If you notice clumps of matter, it's a sure sign that your universe
has exploded.  The matter will usually collapse back into a singularity on
its own; but if it doesn't, try increasing your gravitational constant.



Wed, 18 Jun 1902 08:00:00 GMT  
 DOS compressed date/time into real date/time

Quote:



>[ snip ]

>|> The UNIX people have a 32-bit counter for seconds that
>|> goes negative in 2038.  That may be a problem :-(.

>Only for Unixes with a 32-bit time_t.  UNICOS, for example, has a 64-bit
>time_t and is good for another ~290 billion years which should be well
>beyond the operational life of any Unix-based system, if not the universe.  ;-)

The definition of time_t is deliberately left vague in the actual
POSIX standard.  However there are related standards which
are written to assume the 32-bits is sufficient (for time-stamps
and such).  So, even, if you're using a 128 bit time_t, much
software must chop that down to 32 in order to comply to the
other standard forms and for interoperability.  Still, it's 38
years in the future.

--
J. Giles



Wed, 18 Jun 1902 08:00:00 GMT  
 DOS compressed date/time into real date/time

Quote:

> So, even, if you're using a 128 bit time_t, much software must chop that
> down to 32 in order to comply to the other standard forms and for
> interoperability.  Still, it's 38 years in the future.

Good OSes, even when they stick to 32 bits, treat time_t as unsigned. In
that case, we have another 106 years to go. OTOH, I fully expect to come
out of retirement circa 2035 or so to help patch all those applications
where that isn't the case...

        Jan



Wed, 18 Jun 1902 08:00:00 GMT  
 DOS compressed date/time into real date/time

Quote:


> > Still, it works just fine if you only use up to bit 15 in each word.
> > But I thought Intel machines were little-endian.  Shouldn't these be
> > displayed in reverse order?

> But did you noticed something more important than just typo?

> In 2045 date counter will start again from 1980!

True.  This date and time format is out-of-date for Win32 programming,
as they now use SYSTEMTIME (a full WORD devoted to the year) and
FILETIME (a 64-bit number counting 100-ns intervals from sometime in
the 1600's, not sure when it runs out).

Some time structures in C programming run out in 2038, as well, though
it's possible that a recompile with a different internal definition
of a variable type will fix that.

--
Craig Powers




Wed, 18 Jun 1902 08:00:00 GMT  
 DOS compressed date/time into real date/time

Quote:


> >      !    Date:   0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16
> >      !            +-day---+ +-mon-+ +-year---------------+ (year offset
> >from 1980)
> >      !    Time:   +-sec/2-+ +-minute---+ +-hour----------+ (values
> >count from 0)

> Seven{*filter*} bit words?

:-)

Gotta fix the documentation, I see.  Yes, they are supposed to be
16-bit words.

Quote:
> Still, it works just fine if you only use up to bit 15 in each word.
> But I thought Intel machines were little-endian.  Shouldn't these be
> displayed in reverse order?

Strictly speaking, yes.


Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. Create Time / date or Modified Time / date of a txt file

2. convert labview date/time to excel date/time

3. Clarion Date (Long) -> Access Date\Time

4. how to get the real time and date?

5. time to time with different dates...

6. TIME&DATE in HTML shows TIME

7. Unix time to calendar date/time?

8. showing time + date from dos interupt

9. how to do dos date and time commands

10. Dos Date & time to clarion date & time

11. Time to REAL & REAL to time

12. Question: how to convert a local Date & Time to UTC Date & Time

 

 
Powered by phpBB® Forum Software