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

Re: [ISO8601] Is "2003-11-22 13:30:15" an ISO-8601 date in your opinion?

Expand Messages
  • Fred Bone
    ... It s identical to the same rubric in the same section of the 1988 edition. However, it says omitted , not replaced by a space . Spaces do not occur in
    Message 1 of 27 , Jan 23, 2004
      "Per Johansson" wrote:

      > --- In ISO8601@yahoogroups.com, "jusjih" <jus168jih@s...> wrote:
      > > --- In ISO8601@yahoogroups.com, "Per Johansson" <per@j...> wrote:
      > > > --- In ISO8601@yahoogroups.com, Jan Boström <jan@s...> wrote:
      > > > > As you state, strictly speaking "2003-11-22 13:30:15" is not an
      > > ISO
      > > > 8601 date. You could of course consider it an ISO 8601 date followed
      > > > by an ISO 8601 time, but since the date and time are related it
      > > would
      > > > not be correct.
      > >
      > > It's true. A note under 5.4.1 of ISO 8601 Final Draft dated 2000-12-
      > > 15 says that the letter T may be omitted if readily understood.
      > >
      > I didn't even know that. Haven't read the new final draft in detail.

      It's identical to the same rubric in the same section of the 1988

      However, it says "omitted", not "replaced by a space". Spaces do not
      occur in ISO8601 representations (see 4.4 in the 2000 edition, 4.3 in
      the 1988 one).
    • Fred Bone
      ... It s not the least confusing for the target audience: a program. And as mentioned previously, spaces have no place in ISO8601 representations.
      Message 2 of 27 , Jan 23, 2004
        NGUYEN Adam wrote:

        > The '03:00-05:00' looks pretty confusing to the average reader.
        > Maybe this should be changed to '03:00:00 local time' and mention of what
        > location the event happened in or '03:00:00 (UTC+/-xx:yy:zz)'?

        It's not the least confusing for the target audience: a program. And
        as mentioned previously, spaces have no place in ISO8601
      • NGUYEN Adam
        I agree again here. Date and Time for everyday use makes sense because uses very simple language. Human-oriented Date Representation should only be used in
        Message 3 of 27 , Jan 23, 2004
                   I agree again here. 'Date and Time for everyday use' makes sense because uses very simple language. 'Human-oriented Date Representation' should only be used in technical & standards documents.

                   Maybe even "zero hour", "zero thirty", "noon", and "twenty-three fifty-nine" would suffice for the talking clock saying 00:00, 00:30, 12:00, and 23:59?

                   Here's my suggestions for a standard date for everyday use:

          All Numbers (Full only): 2000-01-08
          Long-hand English (year-month-day): 2000 January 8 (Saturday)
          Short-hand English (year-month-day): 2000-Jan-08 (Sat.)
          Long-hand English (day-month-year): Saturday, 8 January, 2000
          Short-hand English (day-month-year): Sat., 08-Jan-2000

          Notice that only full dates are shown. Even though some of them are short-hand, they still get the whole message across, unlike the current practice of who knows how many different short-hand date format schemes. The 'All Numbers (Full only)' and 'Short-hand (year-month-day)' formats have the advantage of being able to fit nicely in tables for people to look at in a page.

                   I didn't include there how to say them but, they should all be said in any of the two following ways: 'Saturday, the eigth of January, two thousand' or 'two thousand, January eight, Saturday'.

                   Times should be in the 24-hour format, with whatever amount of precision needed. If the deciseconds (like 23:59:59.9) aren't needed, don't use them. If is all that's needed is just the hours & minutes, just use those, to keep it simple. It's good to know that it's possible to use such precision in a date & time, but it isn't always required. Usually times should be verbally expressed in 'zero hour(s)' (00:00) or 'seventeen forty-six' (17:46) forms, for times on the hour and times within the hour.

                   Timezones in international use such as the Internet, the aviation industry, or any other international industry shouldn't be used at all and instead, replaced with the UTC equivalent dates & times and those dates & times should be appended with a space and 'UTC' ( UTC). For normal everyday use, like talking on the phone, or a televsion or radio broadcast that people in more than one timezone may be watching or listening to, a sentence like 'Right now, it's Saturday, the eigth of January, two thousand, at seventeen forty-six here in New York City in the US.' should suffice.

                   Combinations of date, time, and timezone for international use are below:

          2000-01-08 17:46 UTC
          2000 January 8 (Saturday), 17:46, UTC
          2000-Jan-08 (Sat.), 17:46, UTC
          Saturday, 8 January, 2000, 17:46, UTC
          Sat., 08-Jan-2000, 17:46, UTC

                   For local use, just omit the ', UTC' and ' UTC'.

          At 2004-01-23 10:26 (UTC+0800), you wrote:[...]
              As a language instructor, I try to teach simplicity.  I find "Human-oriented Date Representation" a  little too complicated. 
          I would say: Date and Time for everyday use.
              Having said this, I would like to make ISO 8601 to be user-friendly for everyday users, like office clerks, shipping agents, lawyers, all non-technical professionals, or even homemakers who use calendars and answering machines in their daily lives.
              I want my 'talking clock' to show 00:30 and say "zero hour thirty", or even "half an hour after midnight" will suffice.
              We've heard from computer programmers who tried to settle the issue on systems talking to each other, then systems talking to people and vice versa.  Now we need  suggestions that give a 'plain English' version of ISO 8601, one that leaves room for personalization.
              My uncle in Hungary would like to add the name of the day to 2004 01 26  but he would want to be technically correct.  To him, Monday is hétfQ, to our Swedish friends it is probably mandag, To the French it is lundi, and to thirteen hundred million Chinese  Monday is xinzhi yi = Day One.
              The standard date should fit into any language, with margin left for expressing the name of the day in parentheses.
            Similarly, mm 01 (month) should be numeric with allowance for the name of the month, as in January -- Janvier -- Jänner -- januar etc to add the human touch.
            Historic year designations, such as year 5000+ for the Jews, 4000+ for the Chinese, yet again different years for the Japanese and the Taiwanese, should be relegated to the history books or to the religious commemorations.  The world-wide standard for yyyy is the current 2004.
              In telling the time, 13:30 should be qualified whether it is GMT, UTC, or what time zone.  Where ever the summer daylight time deviation exists, it should be noted. 
            It is seldom necessary for ordinary people to verbally express seconds, therefore 13:30 can be said in English as "thirteen-thirty" without adding the words "hour" and "minutes" in most cases.  If any doubt, one can add "thirteen-thirty p.m.". 
          European languages have already established their own methods of expressing time verbally, so my suggestion aims at standardizing English only.
              We need suggestions as to the writing and saying world standard date and time in English, while adding that other nations should be able to write the correct date and time without having to learn a huge vocabulary of English words.
          Budai, Andrew — Taiwan        2004 01 23 (Friday) 10:19

          Incoming mail is certified Virus Free.
          Checked by AVG anti-virus system (http://www.grisoft.com).
          Version: 6.0.566 / Virus Database: 357 - Release Date: 2004-01-22
        Your message has been successfully submitted and would be delivered to recipients shortly.