[ISO 8601] Re: Date Formats.
- Esther Palmermo <estherpalermo@...> wrote:
> I am looking for a summary of local time, and date formatting for[2001-Oct-31]
> 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,
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
I hope these notes help, but without knowing more about your
questions, some of my thoughts might be off-topic to your ideas.