No announcement yet.

Date$ System Variable Update

  • Filter
  • Time
  • Show
Clear All
new posts

  • Date$ System Variable Update

    Has anyone seen the following problem?

    An application reads the Date$ and Time$ system variables and
    displays the information on an LCD every five (5) seconds for
    reference purposes. The Time$ variable appears to work OK just
    after midnight but the Date$ variable does not advance by one

    If the application is shutdown and Date is typed at the DOS
    prompt, the correct date is displayed on the screen. Is there
    some function that allows MS DOS to process background tasks
    like updating the Date$ system vairable that needs to be

    Any thoughts would be appreciated.


  • #2
    Phil ..

    How long does this effect last until the date returned is correct?
    Or does the effect continue and never 'solve' itself. In that the
    boxes here are all on GMT time and 'midnight' rolls at six in the
    evening here, I can easily and think I will test this with a snip
    for PB 3.5 in an OS/2 DOS-VDM. If what you have found is true here
    I really do need to know it! If I'm where I can do this today I'll
    post the answer back this evening 'local' time.

    Mike Luther
    [email protected]
    Mike Luther
    [email protected]


    • #3

      There is a slight correction to my problem statement. When the
      application is shutdown and the date checked by typing date to
      the MSDOS prompt, the bad date is still shown so the application
      appears to be displaying just what the MSDOS system variable is

      The date was set to 12-08-2003 two days ago and the application
      started executing. Two midnights later, the display is still
      reading 12-08-2003. We shut the application down this morning
      and date reads ... 12-08-2003. The application has no obvious
      errors now including logic flow and using grep, I've been unable
      to find anywhere that we are writing to Date$. Hence, I'm
      sitting here scratching my head trying to figure out why date is
      not updating properly.

      Phil ...



      • #4
        Originally posted by Phil Porter:
        ...displaying just what the MSDOS system variable is carrying.
        Sounds to me like you have a problem with the system board or
        the BIOS (probably the latter). Check with the mfgr of the BIOS
        and see if they have an update.

        There are no atheists in a fox hole or the morning of a math test.
        If my flag offends you, I'll help you pack.


        • #5
          The thought about the system BIOS sure leaps out at one.. Looking at
          the docs for PB 3.5 yields the following snip:

          DATE$ cannot be used to read or set the battery-operated clock/calendar
          found on many PC expansion cards.
          That's obviously part of the PB docs for a good reason. Since the
          reserved word DATE$ is used for both recovery and setting purposes,
          seems thoughtful to me that there may already be known issues where
          some form of assembler code the PB has to be using is incompatible
          with some forms of hardware and the underlayment code which serves it.

          The thought that comes to mind is that some curious form of mis-function
          is involved where the read form of the code also, in this case, for
          hardware incompatibility, also resets the system date while the
          application reads it as well. Could this be an unwanted 'loop' of
          some kind?


          Phil mentions, "While the application is in shutdown.." What does
          that really mean here? Unless the application is a 'TSR' of some
          kind, and shutdown means this TSR is 'shut down', leaving the 'normal'
          access to the operating system still running, how does one test for
          MS-DOS system date, unless this is a true multi-tasker operating
          system, WIN-95 upwards, DesqView, DoubleDOS, OS/2, DOS-EMU from LINUX.
          That isn't on the table yet. If this application is a TSR in DOS ...
          anything might be 'true' in 'shutdown'! I think in what little I
          know about them, that the DOS operating system doesn't know anything
          about what that TSR is doing, or how it has affected certain system
          functions so that normal interrupt driven processes can do what is
          really needed with them. When one writes and uses TSR's one has to
          carefully provide of the TSR to pass and receive critical data in
          and out of it such that the host DOS system doesn't get lost in the
          normal functions.

          Some of the hardest to trace and strangest errors can be produced in
          the TSR disk operations in re ghost multiple same name files for
          multiple un-closed file handles and corrupted FAT tables in DOS you
          have ever seen where the TSR doesn't properly handle file I/O and
          the host DOS operating system doesn't know about any of this. If
          this application is accessing the 'DOS' date in such a way, somehow,
          so that the foundation BIOS/hardware support for this is 'locked' and
          waiting for a reset byte pattern .. and the 'real' DOS can't update
          this data in the BIOS, presto .. what Phil sees will happen.

          In a complex sort of way, a multi-tasking operating system is like
          a huge glorious TSR. I like to think of them as one with at least
          a reasonably well documented form of interfaces on how all the little
          'TSR-kids' have to behave in talking to Mom or Pop, as you might look
          at this in humor. Is this, for example, in humor here, just a bad
          kid, grin?

          The important thing is that PB already documents that in some cases
          hardware and underlaying BIOS code can't handle DATE$ functions.
          It will be interesting to see how this solves out.

          Just thinking on the keyboard here.

          Mike Luther
          [email protected]
          Mike Luther
          [email protected]


          • #6

            I ran into something very similar to what you are describing. What I
            did to solve the problem was to use the TIMER keyword.
            Something like

            IF TIMER => 0 AND TIMER =<60 THEN
            Refresh Date$ in App
            END IF

            In my case, I had a screensaver that displayed the date and without
            this routine, the date would not change automatically.


            Gary Stout
            [email protected]
            Gary Stout
            gary at sce4u dot com


            • #7
              Greetings --

              When I want to refresh the Date Display, I use this
              Select Case ChangeDate$
                Case "23:59:59","00:00:00", "00:00:01","00:00:02"
              ' code to update display of date
              End Select
              Thanx-A-Lot and Enjoy, Frank -- My PB

              [This message has been edited by Frank Ferrell (edited December 10, 2003).]


              • #8
                The thought about the system BIOS sure leaps out at one.. Looking at the docs for PB 3.5 yields the following snip:

                "DATE$ cannot be used to read or set the battery-operated clock/calendar found on many PC expansion cards."

                That's obviously part of the PB docs for a good reason.
                I believe, at least originally, that was intended to refer to ancient XT/AT PCs where a RTC capability was not a native part of the system and usually had to be added by plugging a third-party ISA card into one of the PCs expansion slots, much the same way as how expanded memory was originally implemented. Being a separate (and proprietary) piece of hardware, the OS functions for maintaining the system clock (date/time) usually knew nothing of this hardware and were thus unable to update it.

                This, of course, doesn't discount the possibility that there may be a similar issue affecting some more modern computers.

                If you try to make something idiot-proof, someone will invent a better idiot.
                If you try to make something idiot-proof, someone will invent a better idiot.


                • #9
                  The hardware clock is not read with DATE$. I would suggest bypassing the DOS system date and time (which have been thick with problems since DOS v1) and reading the real time clock directly using BIOS INT 1A, functions 04 and 02

                  From "DOS Programmer's Reference" by Terry Dettman and Allen L. Wyatt, Sr. sum things up:

                  During system startup, the date and time are initialized ... from values in the internal clock. From this point, the time is kept in the BIOS data area and the date is kept in COMMAND.COM.
                  In some versionsof DOS v3, a bug prevents the date from changing when midnight rolls around...
                  Even with the correcion, however, a design flaw in the date routines can cause entire days to be skipped. For example, if a computer is left running over the weekend and no one uses it for more than 24 hours, including two midnight passages, only one of the passages is recognized. The passing of midnight sets a flag rather than a counter, DOS does not know, therefore, when more than one midnight has gone by since the last time it asked...
                  The most direct cure is to reboot the computer every Monday morning to reset the system date.


                  [This message has been edited by Jerry Mason (edited December 16, 2003).]


                  • #10
                    phil, under what operating system(s) has this problem occurred? is it repeatable? how old is the hardware? (bios date?)

                    while you say that using date at the command-line shows the correct date, does the app continue to show the wrong date if the app is restarted from the command-line?

                    ps: if you are running a dos app under an nt-based version of windows, then please be aware that the dos time/date can vary/drift from the time/date shown by windows because the dos emulation is set to match the windows time/date at startup, and the dos emulation maintains its own time/date from that point... see

                    powerbasic support
                    mailto:[email protected][email protected]</a>
                    mailto:[email protected]