No announcement yet.

Storing date in 2 bytes

  • Filter
  • Time
  • Show
Clear All
new posts

  • Storing date in 2 bytes

    Old technique from the year back where you tried to save space to store your data.
    This code is for real men who are still writing their own data base.

    Take 2 separate bytes and make use of all the bits 0-255
    199 and 231 will be the maximum needed well below the maximum

    The 99 part will be the year range from 2000 to 2099
    The 31 part will give us the day range from 1 to 31
    For the month part we will use the 1 and the 2 left over for a range of 1 to 12

    It can be done with a string or math formula but I have never tested to see which was the fastest.
    Any opinion ?
    Old QB45 Programmer

  • #2
    The windows date is an integer currently at 37xxx and can be stored in a word.
    This date value is used in all kinds of ms products.

    ms uses a double to store this value and the fraction is the time.


    • #3
      Similar concepts have been done for many years particulary in Cobol. Surely you heard of the millenium scare. Early programmers never considered their code would still be used in the year 2000, how does your suggestion handle 2100 onwards? Real men think about the future past their own interests
      Last edited by John Petty; 13 May 2009, 03:51 PM.


      • #4
        I know John,

        This is the code I have been using in QB45 but as I am rewriting everything in PB I intend to use a bit more space for the date and time.
        I also used long integers to store my amounts in cents and I will now use the wonderful @@ option.
        I guess we can afford the space now.
        Old QB45 Programmer


        • #5
          Guy, I store all dates/times in the Windows FILETIME format (a QUAD value). Makes it convenient to do math on it or convert it to a SYSTEMTIME structure or use with the Windows API functions/controls.
          Bernard Ertl
          InterPlan Systems


          • #6
            2-byte julian

            2-byte julian dates sort correctly and allow date math.

            PowerBASIC and related source code. Please do not post questions or discussions, just source code.

            Read your second posting and it says you are going to use more space.
            Not sure why you are interested in two-byte dates. If you are, this works great.
            The base year, epoch, could be increased. 4-byte dates using astromath might also work fine.
            Search for julian. If space isn't an issue then use the 8-byte dates.
            Last edited by Mike Doty; 14 May 2009, 05:56 AM.


            • #7
              Julian date


              I know all about the Julian date and have been using it for over 20 years.
              You had to use it for Bank transactions by modem.
              The 2 byte date system I showed yesterday was the one I developed in 1980 and it worked so well that hundreds of my customers still have that kind of data base in their computers. If it's not broken...
              You could not use more than 2 bytes in a 16 byte transaction and since my base year was 1980 it is still good until 2080.
              Some of my old customers have kept all their old data and still can view their 30 years old accounting statistics because it use so little space.
              I may end up by adding a third byte for a new system.
              Unless I give up my miserly way about wasting space and simply adopt MS system.
              Old QB45 Programmer


              • #8
                Old technique save space ...for real men ..
                Real Men don't have angst about two bytes here, two bytes there.
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]


                • #9
                  Real men

                  You are my favorite curmudgeon and I will forgive you because you are the main source of that good info in that Forum !
                  But how you can find the time to do it.....
                  Old QB45 Programmer


                  • #10

                    Last September I was visiting, with all my family, your breathtakingly beautiful 400 years old city of Quebec. At 66, and being a former TB programmer, I think we are being forced not to walk, but to run ahead.


                    • #11
                      Originally posted by Michael Mattias View Post
                      Real Men don't have angst about two bytes here, two bytes there.
                      Somehow I'm reminded of Senator Dirksen's (Goldwater ?) remark "You know, a million here, a million there. Pretty soon you are talking about real money."

                      Lazy people are always anxious to be doing something.
                      Luc, Marquis de Vauvenargues
                      It's a pretty day. I hope you enjoy it.


                      JWAM: (Quit Smoking):
                      LDN - A Miracle Drug:


                      • #12
                        Mike, if you use a date like 12-31-1950 for day 0 then you can use the 2 byte date for Depreciation too. (have to have acquisition date old enough to allow at least 40 years of service for some assets)

                        Guy - trouble with using cents is it only allows +- 20 mil or so.(before we got cux)

                        I used to use (and still do for compatibility), long integer for whole dollar amount + 1 byte for cents. so a total of 5 bytes for +- 2 billion. (MKL$ + chr$() )

                        It is longer to do that (no pun intended) because I have to check for negative cents and change it.
                        Client Writeup for the CPA


                        Links Page


                        • #13
                          I forgot to mention the code was modified to allow a LONG in 2005.
                          If using a julian of -29219 to 31368 it also works with 2-bytes.

                          I believe there is a problem in QuickPak's Date2Num(-29160).
                          This returns 2/29/1900, but 1900 was not a leap year.
                          This was corrected in 1995 by Ethan Winer in version 4.20.
                          Last edited by Mike Doty; 15 May 2009, 02:19 PM.


                          • #14
                            I just figure the days from 1/1/0000 to present (really no year 0) subtract the days from 1/1/0000 to 12/31/1950 and store as a word then add it back to show the full date which is 4 character year. That should go until the year 2100 sometime.
                            Client Writeup for the CPA


                            Links Page


                            • #15
                              Somehow I'm reminded of Senator Dirksen's (Goldwater ?) remark "You know, a million here, a million there..."
                              It was Everett M. Dirksen of Illinois. Except I remember it as "a billion here, a billion there...."

                              Makes you wonder how it will be remembered in the Age of Obama.
                              Michael Mattias
                              Tal Systems (retired)
                              Port Washington WI USA
                              [email protected]


                              • #16
                                Storing dates in 2 bytes

                                I've gotten lazy in my later years and use 4 byte long representing the number of days since Jan 1, 1. I have an entire DLL of date and time functions based on it and even use mostly LONG/EXTENDED internally within that DLL. Hmmmm. it might even be useful to post the DLL source in case anybody wants to snatch parts of it though it will have to wait until I get all the other calendaring systems in there. I only have Gregorian/Julian/ISO tested as I took a break to add all the interesting astronomical functions for the moon and sun (sunrise/set, moonrise/set, seasons, etc) and really want to figure out how to incorporate the Olson timezone data somehow/somewhere.

                                Datetime i use a DOUBLE representing the number of milliseconds since Jan 1, 1.
                                Last edited by Rick Kelly; 15 May 2009, 07:19 PM.

                                It has come to my attention that certain dubious forces are interpolating their desires in my search for Mom, apple pie and the girl you left behind. Stop it or I'll scream...


                                • #17
                                  If you don't have any moral objection to using 8 bytes, using a FILETIME is a good way to keep dates and times... they are time-zone agnostic (always UCT) and there are lots of math routines available.

                                  Just remember to convert everything to filetime (not local filetime) before storing.
                                  Michael Mattias
                                  Tal Systems (retired)
                                  Port Washington WI USA
                                  [email protected]


                                  • #18
                                    Using a couple of bytes for your own app or one in which there is no interface to an MS Office or similar app... ok. But when the app stores its data in the MS app then many of us probably use the double.

                                    Currently i have a development using MS Access where I get the local time ... no sweat it for the home office and even if there are branches, chances in the 99.99th percentile they will be in the same time zone too ... so

                                    So this app uses GetLocalTime -->SYSTEMTIME var
                                    Then only a pair of functions are needed to move to and from MS Access storage/use in this case,

                                    Misnomered functions in that they move between the quad SYSTEMTIME and the MS double value.

                                    But in the same app I am using bit arrays to store the settings of up to 128 checkboxes, options and other settings. Even have some reserve there for future expansion.

                                    Michaels point about FILETIME should be heeded though for those with multiple time zone needs. In my case we typically only need the day, but if push comes to shove we have the time values there to compare as well.
                                    Rick Angell