Loading ...
Sorry, an error occurred while loading the content.
 

Supporting all of ISO-8601 date formats is significant!

Expand Messages
  • hjwoudenberg@aol.com
    See attachment for a word copy. Any Date Globalize your e-Business The need: IBM ¾ “Globalizing your e-business is no longer a luxury, it is a necessity. As
    Message 1 of 3 , Jun 5, 2004
      See attachment for a word copy.
       

                                          Any Date

      Globalize your e-Business

      The need:

      IBM ¾ “Globalizing your e-business is no longer a luxury, it is a necessity. As the Internet transcends national and geographical boundaries, the concept of doing business within a single country is quickly giving way to the need to compete in an international marketplace.”

      The problem:

      IBM ¾Neither the CORBA (Common Object Request Broker Architecture) nor the J2EE (JAVA) specifications address time zone issues adequately and conventional methods of solving this problem are limited. The concept of Daylight Savings Time further complicates the time zone issue.”

      The solution:

      Any Date converts any format of date, time and time zones from any place in the world to any other format any other place in the world with the necessary daylight adjustment.

       

      Any format means:

      From the small “4/8/04”

      To the large “Thursday, April  4/8/2004 1:15pm –05:00 CDT  Chicago,IL,USA”

      Or the ISO-8601 standard “2004-04-08T13:15:00”

      And including user custom formats.

      Any place means:

      Over 200 countries, every country recognized by the United Nations

      Over 2000 cities, islands or locations that have an IATA airport code.

      The international time zone abbreviations.

       

      Date conversion is frequent with business applications.  This makes speed important.  Any Date was able to achieve phenomenal speed by using:

      1.        The ladder approach to system design as is used so effectively in Unix and Linux.

      2.        New features that allow, after climbing up the ladder, jumping down rather than climbing down.

      3.        Maximize RISC CPU pipeline ability as recommended by Frank Soltis, the chief engineer for the IBM Power CPU.

      4.        Cashing a technique also used in CPU’s to improved performance.

      The result, all of Any Date’s functions are faster than the equivalent native functions or API (application program interface), with one exception. 

       

      Prior to the Internet, date parsing code could be generated at compile time.  Globized e-business has changed that and requires the date parsing be determined at run time, similar to Java.  The following timings show how slow this can be and how fast Any Date can do this function.  All timings are for 1 million date conversions on an IBM AS/400 model 270, a small model.

       

      Conversion                                 Time in seconds

      Date only, parsed at compile time 36 traditional local country method

      Native routine, date parsed at run time 1,604 date format a variable, global method

      Any Date date only 146 date format a variable, global method

      Any Date date and time 150 date and time are a variable

      Any Date time zone to time zone 901 time zone offset conversion

      Any Date country-to-country 2,075 the time zones are determine from country codes

      The last country code conversion has a table that gives the time zone offset, the daylight rules and the format for each country, state and region. 

       

      Any Date is fast and full featured making it difficult for any future competitive product.  Both standard and unique programming tools were used to minimize the time to 10,000 man-hours.  As a full-featured product, it requires 50,000 line of code, half for the date conversion function and half for maintenance and other support programs. 

      Commercial Software Services, Inc.  (CSS)

      100 Park Ave #614

      Calumet City, IL 60409

      Phone 708-891-2239    Fax 708-891- 2341

      e-Mail hjwoudenbeg@...

      Explanation of Format Conversion Requirements

       

      Internally the computer date and time format is YYYY-MM-DDThh:mm:ss, the International Standard (ISO-8601) used for computer-to-computer (B2B) communication.  This format also correctly sorts dates while MM/DD/YYYY and DD.MM.YYYY formats do not.

       

      The problem:

      The MM/DD/YYYY format is used in North and South America, the DD.MM.YYYY format is used in Europe and Africa and the YYYY-MM-DD format is used in China and Japan.  Next other countries use different separators (-/.,) with any of the three formats, there is no standards.  Also the European Union and other nations are switching to the YYYY-MM-DD format and therefore the system must allow changes. 

       

      Utility countries have many bill and many dates and therefore thy need the speed of constants (*MDYY/ or *MDYY. abbreviation for the format) that can be specified at compile time. The compiler generates the specific unique instructions to parse the date.  However, most software has much less volume and the use of a constant requires the programs to be changed and recompiled when used in a country with a different format. 

       

      With globolized E-Business, transactions to transaction can be from different countries and have different formats.  A transaction from Europe will have a different format than from the US.  This requires the use of variable for the format allowing the format to be can changed from transaction to transaction. 

       

      In addition, when the dates are from humans they must be checked that they are a valid date.  An invalid date can cause a program to crash.   

       

      Test date & time                               Type of conversion                               Time in seconds

                                     Native                               43
                                     Any Date                               5                            

       

      Any Date combines the parsing and testing and therefore the testing is only the small marginal increase of 5 seconds.  Therefore, when parsing a date Any Date always validates the date and time. 

       

      As a result Any Date can globalize:

      • Most batch software because it’s speed.
      • The e-business because of the features.  The e-business has continued to grow during the last USA business downturn and grew twice as fast in Europe and Asia.

       

      Explanation of Time Zone Conversion Requirements
      Universal Time Offset (UTO)

      The problem:

      ·         Date alone can be wrong for half the world. 

      ·         Most people do not know the time offset for time zone abbreviations like “CST=-6:00 or CDT=-5:00” for North America.  Most Americans do not the offset for European time abbreviations or even for Hawaii or Alaska.  

       

      Time Zone Offset conversion is complicated by:

      • The 31, 30 and 28 day months.
      • Leap years.

       

      Astronomers have developed a simple and fast solution for time zone conversion.  Astronomical events are cyclical based on elapsed days, not years like birthdays.  Many astronomers are excellent mathematicians and they developed formulas that convert Gregorian dates to days,  and days back to Gregorian dates.  For time zone conversion the days and time can be converted to seconds, adjust the seconds by the offset, and convert seconds back to days and time. 


       

      The time zone conversion steps using astronomical formulas are:

      1. Convert human readable characters to the computer binary integers. 
      2. Convert the Gregorian binary integers date to binary days and than seconds using the astronomer’s formula.
      3. Convert time zones to seconds and add the difference of the two time zones.
      4. Convert the binary seconds to days and than Gregorian binary integers using the astronomer’s formula.
      5. Convert binary integers to human readable characters.

       

      The times for 1 million conversions:

       

      Native                               Type of conversion                               Time in seconds

                                     Convert characters to binary 32 no testing if date and time are valid
      Convert Gregorian to seconds 148
      Time zone conversion 0
      Convert seconds to Gregorian 140
      Convert binary to characters 13
      Total 333

       

      Any Date                               Type of conversion                               Time in seconds

                             Convert characters to binary 21 includes testing if date and time are valid
      Convert Gregorian to seconds 90
      Time zone conversion 0
      Convert seconds to Gregorian 297
      Convert binary to characters 13
      Total 416 83 seconds slower

       

       

      The conversion of seconds to Gregorian date is the one exception when IBM does it faster.  We have no idea how IBM does it so 2.5 minutes faster.   

       

      However, the API function cannot be used because different computers use a different epochs to start the first second.

      Computer                Starts                      Overflow (a binary Y2K) type problem

      Unix                        1970-01-01                2038

      Microsoft                1983-01-01                no info guess 2051

      Macintosh                1904-01-01                no info guess 2062

      GPS                         1980-01-01                no info

      NTP                        1900-01-01                2036 an integer time used for Internet communication.

      Native IBM                 1582-10-14                9999-12-31 started the first day of the Gregorian calendar

      Any Date                9999-01-01BC                9999-12-31AD

       

      The ISO (International Organization for Standards) and the ICU (International Components for UNICODE) specify BC and AD eras.  IBM’s CPUs are 64bit and therefore can support the range of dates from –9999-01-01 to +9999-12-31.

       

      Any Date features:

      1. Very fast.
      2. Easy to use.
      3. Comprehensive.
      4. User friendly.  
      5. Flexibility.
      6. Time zone rules maintenance from a central server¾allowing centralized maintenance.
      7. Uses static call for speed but runs as a service program¾only one copy is in the computer memory. 
      8. Exceptionally well documented.

       


       

      Any Date features resulted because it was developed professionally.

      1. Architecture need:
        1. Resulted from an Internet project for one of the 10 largest banks in the world and from opinions of others.  A valuable feature would have been to convert US time to the user local time and vice verse.  
      2. Research.  The Internet was searched for available products.  The results revealed almost all of them:
        1. Lacked comprehensive and important features.
        2. Were difficult to use.
        3. Ran slow.
        4. Usually the rules were hard coded making changes difficult.
        5. Did not have an easy method of maintenance.
      3. Consulting:  The technological requirements selected:
        1. Must be ISO-8601 (International Organization for Standardization) compliant. 
          All international formats have the year first, require “-“ and “:” for date and time punctuation.  Have the following requirements:

                                                                     i.      ± dates.

                                                                    ii.      Gregorian dates.

                                                                  iii.      Ordinal dates (Julian dates).

                                                                  iv.      Week-of-the years dates.

                                                                   v.      Time maybe hours-minutes-seconds, hour-minutes, or hour alone.

                                                                  vi.      Fractions of time maybe fractions of seconds, fractions of minutes and fractions of hours.

                                                                vii.      Universal time offset formats maybe ±00:00 or just ±00

        1. Must be ICU (International Components for Unicode) compliant.  This requires support for:

                                                                     i.      The 12 hour am and pm time.

                                                                    ii.      Support local format and punctuation like MM/DD/YYYY and DD.MM.YYYY 

        1. Must be SQL compliant.
        2. Must be compliant with COBOL86 and IBM formats.
        3. Support B2B (computer to computer) which is strict conformity of data and format or else it’s an error.  

      Format “*DD/MM/YYYY hh:mm:ss”  must match exactly or it is any error.

        1. Support B2C (computer to consumer) that permits general formats allowing flexibility with the dates.

      Format “*Ms” permits     MM/DD/YYYY hh:mm:ss or hh:mm or hh

      And                 YYYY-MM-DD hh:mm:ss or hh:mm or hh.

        1. Programs would be developed to back-test all combinations of the format conversions.  After a date is converted, it is than converted back to the original date and checked that the results are the same as the original.  The program highlights any errors.  Programmer can just pages through the display and any errors jump out.
        2. The system was to be designed with the capability for automated table update from a central server.  If a country changes its rules, the change can be made at a central server.  When that country is used on any other server, it is automatically updated.
        3. Would provide the ability for a user to make custom formats.   On reason is that ISO-8601 provides for basic formats that do not have punctuation.  The custom feature supports these formats  plus any other possible format user format.
        4. Would write a program to create all possible errors.  It would put invalid data in each position and verify that an error occurred and it did not crash.  This includes characters such as *LOVAL X’00’ and *HIVAL X’FF’.
      1. Project management.  It had these phases:
        1. Phase 1. Program functions were developed to simplify the use of User-Indexes and User-Space. IBM wrote that they were significantly faster than database files.  Also any module can access a user space tables because they do not require an open or close.  We developed commands that give the same flexibility of change to user-spaces that database files have.  Adding fields, changing the size of fields, etc is almost as easy as with database files.  -Three months.
        2. Phase 2.  Program the ISO-8601, ICU, SQL and IBM format conversion with no time zone conversion in 6 months.
        3. Phase 3. Program Time zone conversion development 6 months.  Foreign servers have a two-letter ISO-3166 A-2 code as the top-level domain.  The United Nations has assigned to every country in the world a two-letter ISO-3166 A-2 code.  It is also the top-level domain code for non-US servers.  This is used for the from and to locations.  The US in the future is to have both the country code and the state code, the same as “Any Date”. 
        4. Phase 4. Integration and rewrite to simplify. The two-step approach is easier to program, but runs slow.  Therefore, we convert form one place to another without converting to GMT as an intermediate step..
        5. Phase 5. Finally rewrite and optimize for speed.  Three months.  The efficiency was improved, the organized was improved, the documentation was improved and all unnecessary code was removed.
      2. Analysts.  Developed system specifications:
        1. Documented field and message functions and program them.
        2. Documented User-Index Table and User-Space table functions and program them.
        3. Documented time conversion functions using binary integers for speed.
        4. Documented the format conversion requirements.
        5. Documented the time zone conversion requirements.
      3. Programming
        1. ILE was used because it provides powerful function features and the Export/Import feature makes global data available at the top of the ladder without carrying it up the ladder.
        2. Computerized table (file) layouts.  When file layouts are changed, the new layout can be displayed or printed.  The fields can be sorted by name, by size or selected based on character in the name or description.  This is an important tool. 
        3. Computerized the function documentation.  We can print a list of the functions, what they do, their parameters, their type and options.
        4. System rebuild was automated.  We followed the advice of others to recompile and rebuild almost daily during finial system debugging.
        5. Computerized the creation of the service program.  We experience no lost of speed running as a service program and it allow only one copy to be used for all the jobs and all the users.  The adding of new functions and dropping of old ones is automatic, without manual intervention.
        6. Because it is all structured code we found the IBL indented listing inadequate.  Therefore we made a new listing, which puts the “IF’ “DO” “WHEN” statement as a comment after the end statement.  Both to simplify the code and for speed we use “LEAVE” and therefore have a feature to makes it easy to use.
        7. We ran timing on many of the function.  We did not assume.  We would time using native features, IBM’s APIs, and than the new function.  For example our formula to converting from Gregorian to seconds is faster than any published formula we could find and the native API.     

       

       

      No other software is as compliant as Any Date to the:

        1. International Organization for Standards ISO-8601
        2. International Components for UNICODE local formats and time zones.
        3. SQL ANSI/ISO/IEC 9075 standards
        4. IBM and COBOL85 date and time formats

       

      Herman J. Woudenberg

       

       
    • g1smd_amsat_org
      On 2004-06-06 ( ): [2004-06-12] ... binary Y2K) type problem ... Rollover has already happened once. It was 1999-08-21.
      Message 2 of 3 , Jun 13, 2004
        On 2004-06-06 (>):


        [2004-06-12]



        > Computer Starts Overflow (a
        binary Y2K) type problem
        >
        > GPS 1980-01-01 no info

        Rollover has already happened once. It was 1999-08-21.

        http://www.google.com/search?q=gps+rollover+1999+date&num=100&hl=en&ie=UTF-8&btnG=Google+Search



        > International Organization for Standards ISO-8601

        Nope.

        It is the "International Organization for Standardisation".




        Cheers,

        Ian.


        [2004-06-12]
      • johnmsteele
        ... q=gps+rollover+1999+date&num=100&hl=en&ie=UTF-8&btnG=Google+Search ... Agreed. To further correct the GPS info, the actual epoch is 1980-01- 06T00:00:00Z.
        Message 3 of 3 , Jun 13, 2004
          --- In ISO8601@yahoogroups.com, "g1smd_amsat_org" <g1smd@a...> wrote:
          > On 2004-06-06 (>):
          >
          >
          > [2004-06-12]
          >
          >
          >
          > > Computer Starts Overflow (a
          > binary Y2K) type problem
          > >
          > > GPS 1980-01-01 no info
          >
          > Rollover has already happened once. It was 1999-08-21.
          >
          > http://www.google.com/search?
          q=gps+rollover+1999+date&num=100&hl=en&ie=UTF-8&btnG=Google+Search
          >
          Agreed. To further correct the GPS info, the actual epoch is 1980-01-
          06T00:00:00Z. GPS time does not incorporate leapseconds, so it is now
          13 s ahead of UTC. GPS keeps time in seconds (within a week) and week
          number 0-1023. It rolls over every 1024 weeks (7168 days, exactly)
          and it is the responsibility of the receiver to handle rollover.

          Some early receivers handled the first rollover poorly, partially,
          because there was no warning about rollover until 1993-10-10, and
          satellites did not even have week number, until ID#2 launced 1983-
          07. TMI available from here:
          http://www.colorado.edu/geography/gcraft/notes/gps/gpseow.htm
        Your message has been successfully submitted and would be delivered to recipients shortly.