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

[ISO 8601] Re: Date Formats.

Expand Messages
  • g1smd@amsat.org
    ... [2001-Oct-31] Date formatting around the world has been varied for many years, but standardisation is now the key. France 31.10.01, Italy 31-10-01, and
    Message 1 of 1 , Nov 1, 2001
      Esther Palmermo <estherpalermo@...> wrote:

      > I am looking for a summary of local time, and date formatting for
      > major countries of Europe (FIGS: France, Italy, Germany, Spanish)
      > as well as countries in Asia Pacific (Japan, China, Korea).
      > Would this group be able to help me?


      Date formatting around the world has been varied for many years,
      but standardisation is now the key.

      France 31.10.01, Italy 31-10-01, and Spain 31/10/01, have also
      used others, but now mandate only date formats based around the
      2001-10-31 (YYYY-MM-DD) format, through the following national
      France: NF EN 28601 (1993)
      Italy: UNI EN 28601 (1993)
      Spain: UNE EN 28601

      Scandinavian countries have used 2001.10.31 and 2001/10/31, which
      are already in Year-Month-Day order, but have also adopted the
      ISO 8601 or EN 28601 standard in more recent times, through various
      national standards, such as:
      Denmark: DS/EN 28601.

      Germany has used 30.X.2001 and then 30.10.2001 but now has changed
      to the 2001-10-31 format though both the DIN EN 28601 (1993) and
      the DIN 5008 (1996) standards.

      Asian Countries have already generally been using Year-Month-Day
      ordered formats for very many years. These were often in formats
      like 2001.10.31, but hyphens are now allowed as per the ISO 8601
      standard. These have been documented in their official standards,
      such as:
      Japan: JIS X 0301-1992
      China: GB/T 7408-94
      I don't have a number for the Korean standard.
      I found, and then lost, the number for Thailand recently.

      The US has traditionally used 10/31/01, but 2001-10-31 is now
      defined in the ANSI X3-30 and NIST FIPS 4-1 standards.

      The UK has traditionally used 31/10/01, but 2001-10-31 is now
      defined in the BS EN 28601 British Standard.

      This neatly clears up ambiguities that dates like 03/02/01,
      or 03/02/2001, would otherwise cause.

      There are still very many people stuck in their old habits, but
      a lot have changed to the new format, and many more will follow
      as it becomes more well known.

      Perhaps you could explain what it is that you are trying to do, so
      that people here could give more detailed advice?

      Many people are now moving away from trying to cater for hundreds
      of different formats in software, as the benefit of allowing the
      user to select their own format is lost when the data is printed
      out and sent around the world, or is emailed.

      The date March 2nd, 2001 could be shown as 03/02/01 in the USA,
      but when sent to someone in Europe this date will be read as
      3rd February 2001 (or maybe 1901!), and as 2003 February 1st
      by someone in China or Japan.

      This is why so many people are now adopting one worldwide
      standardised format: YYYY-MM-DD. I would urge you to consider
      doing the same. Indeed all new Internet protocols are advised
      to adopt this format, and it is a core part of the way that
      new XML based technologies work.

      For the record, if you try a very good search engine like Google,
      at: <http://www.google.com>, and try a search string like 'ISO8601'
      or 'ISO 8601' (try it both with, and without, the space) then you
      will find several thousand pages on this topic.

      See also: <http://www.qsl.net/g1smd/isoimp.htm>.

      Consider joining the ISO 8601 related discussions, by email, or at
      <http://www.yahoogroups.com/group/iso8601> for further information.

      As for Local Time rules, these are always subject to change due
      to local laws and statutes in force at the time, and other political
      decisions. For countries that operate a 'Summer Time' or 'Daylight
      Savings Time' system, the dates of changeover may not always be
      accurately predictable into the future, for many reasons. Some
      countries in the Northern Hemisphere operate Summer Time from the
      third Sunday in March until the last Sunday in October.

      The current Time Zone information for many countries can be
      found in many places on the Internet, but there is NO central
      register, nor any governing International Standard, Treaty, or
      other Agreement covering this. Countries can change their offset
      and rules at any time that they may wish; and over the course of
      history many have done so, multiple times.

      It is also important to realise that time zones can be up to
      + or - 14 hours from UTC/GMT, and that some zones have a 15,
      30, or 45 minute offset, not just a whole number of hours.
      The ISO 8601 standard uses a 'sign and 4 digits' system to show
      the offset in a simple manner.

      For data files that have to be sent around the world, it is now
      common for the data to be normalised to the UTC (Univeral Time,
      Co-ordinated) Time Zone, a time scale generated by Atomic Clocks.
      This is very closed allied to the old GMT (Greenwich Mean Time)
      time scale. Masses of information on this can be found on the

      Imagine an event that occurs in Japan on Friday 06:00 Japan Local
      Time. In USA Winter, this may occur 7 hours BEFORE, NOT AFTER!,
      an event that occurs in the Eastern USA on Thursday 23:00 USA
      Local Time, but will occur only 6 hours before the USA event
      when the USA is on it's Summer Time (Daylight Savings) Zone.

      The Japanese event occurs Thursday 21:00 UTC
      The East USA event occurs Friday 04:00 UTC in USA Winter.
      The East USA event occurs Friday 03:00 UTC in USA Summer.

      It is not a simple matter of comparing the two Local Times,
      as they are in different Time Zones. It is not easy to subtract
      one time from another adding in the time zone Difference as it
      is further complicated by the movement from Summer to Winter
      (Daylight to Standard) times and back again, during the year.
      This means that the actual date has also to be taken into
      account for this, otherwise calculations may be 1 or 2 hours
      wrong. You also need to use the actual date in the calulation
      if mightnight has to be crossed during the conversion, as
      the resultant date might be different to the starting date.
      Please also note that different countries move from 'Summer'
      to 'Winter' on different dates within the same hemisphere,
      and in anti-phase in the opposite hemisphere (but, again, NOT
      date synchronised). Conversion of all data to a standardised
      UTC scale is therefore very useful, and far more simple.

      You know your own Local Time offset to UTC. Convert your dates
      and times to the UTC Time Zone, then transmit those. Data coming
      from all over the world arrives all in the UTC time scale and
      can be easily sorted into the true chronological order. If the
      end user needs to see the data presented in their own local time
      scale then they can easily convert the data to that format.
      You should not do this at the sending end as you may make a wrong
      assumption as to the receiving persons location or actual local
      time zone, just convert and store everything in UTC Date & Time.

      The ISO 8601 standard therefore allows a worldwide standardised
      way of ordering the individual Date and Time elements to avoid
      problems with 03/02/01 type dates, and provides a standardised
      way of showing times in Local Times and showing their offset
      from the UTC Time Zone, or of converting them to the UTC Time
      Zone itself.

      I hope these notes help, but without knowing more about your
      questions, some of my thoughts might be off-topic to your ideas.







    Your message has been successfully submitted and would be delivered to recipients shortly.