My ISO 8601-based Calendar Generator is as popular as ever, with a few
kind souls making donations once in a while.

* http://WWW.HyperInfo.CA/~HyperInfo.CA/Calendar.html

However, I am forced to translate the CGI, which was originally coded
in HyperTalk, then in AppleScript, into Perl to be run on a UNIX
server.

I am a newbie in Perl, and I am wondering if there are any pre-written
date/time functions (e.g., localtime(), timelocal(), etc.) which
conform to ISO 8601.  If not, I will just have to translate the
AppleScript isoDateTime() function shown below into Perl...

Thank you very much for your attention.
Merci de votre attention.

Prof. Simon Sunatori, P.Eng./ing., M.Eng. (Engineering Physics), F.N.A.
HyperInfo Canada Inc.
--
Simon Sunatori      <http://WWW.HyperInfo.CA/~GS.Sunatori@HyperInfo.CA/>
65, des Parulines   <mailto:GS.Sunatori@...>
Gatineau (Quebec)   <telephone:+1-819-595-9210>
CANADA  J9A 1Z4     <facsimile:+1-425-984-7292>

------------------------------------------------------------------------
on isoDateTime(theDateTime, theOption)
	 try
		 set theReturn to ""
		 set oldDelimiter to AppleScript's text item delimiters
		 set AppleScript's text item delimiters to {" "}
		 set theDateTime to (theDateTime as string)
		 set theMonths to {"January", "February", "March", "April", "May", "June",
"July", "August", "September", "October", "November", "December"}
		 set theYYYY to (text item 4 of theDateTime)
		 repeat with i from 1 to (count of theMonths)
			 if ((text item 2 of theDateTime) = (item i of theMonths)) then
				 set theMM to i as string
				 exit repeat
			 end if
		 end repeat
		 if ((count of theMM) < 2) then set theMM to ("0" & theMM)
		 set theDD to text 1 thru -2 of (text item 3 of theDateTime)
		 if ((count of theDD) < 2) then set theDD to ("0" & theDD)
		 set theTime to (text item 5 of theDateTime)
		 set theDay to text 1 thru -2 of (text item 1 of theDateTime)
		 set AppleScript's text item delimiters to oldDelimiter
		 if (theOption = "date") then
			 set theReturn to (theYYYY & "-" & theMM & "-" & theDD)
		 else if (theOption = "time") then
			 set theReturn to (theYYYY & "-" & theMM & "-" & theDD & "T" & theTime & ",0")
		 else
			 set theReturn to (theYYYY & "-" & theMM & "-" & theDD & " (" & theDay & ")")
		 end if
		 return theReturn
	 on error
		 return -1
	 end try
end isoDateTime
------------------------------------------------------------------------

See http://datetime.perl.org/modules.html.

If there's such a thing, I'd expect it to be there.

There is a "DateTime::Format::ISO8601" Modules that "Parses ISO8601
formats", but not sure about the other way..


> -----Original Message-----
> From: Sunatori, Go Simon [mailto:GS.Sunatori@...]
> Sent: Monday, August 04, 2003 8:09 PM
> To: ISO8601@yahoogroups.com
> Subject: [ISO8601] ISO 8601 Function in Perl?
>
>
> My ISO 8601-based Calendar Generator is as popular as ever,
> with a few
> kind souls making donations once in a while.
>
> * http://WWW.HyperInfo.CA/~HyperInfo.CA/Calendar.html
>
> However, I am forced to translate the CGI, which was originally coded
> in HyperTalk, then in AppleScript, into Perl to be run on a UNIX
> server.
>
> I am a newbie in Perl, and I am wondering if there are any
> pre-written
> date/time functions (e.g., localtime(), timelocal(), etc.) which
> conform to ISO 8601.  If not, I will just have to translate the
> AppleScript isoDateTime() function shown below into Perl...
>
> Thank you very much for your attention.
> Merci de votre attention.
>
> Prof. Simon Sunatori, P.Eng./ing., M.Eng. (Engineering
> Physics), F.N.A.
> HyperInfo Canada Inc.
> --
> Simon Sunatori
> <http://WWW.HyperInfo.CA/~GS.Sunatori@HyperInfo.CA/>
> 65, des Parulines   <mailto:GS.Sunatori@...>
> Gatineau (Quebec)   <telephone:+1-819-595-9210>
> CANADA  J9A 1Z4     <facsimile:+1-425-984-7292>
>
> --------------------------------------------------------------
> ----------
> on isoDateTime(theDateTime, theOption)
>  try
> 	 set theReturn to ""
> 	 set oldDelimiter to AppleScript's text item delimiters
> 	 set AppleScript's text item delimiters to {" "}
> 	 set theDateTime to (theDateTime as string)
> 	 set theMonths to {"January", "February",
> "March", "April", "May", "June", "July", "August",
> "September", "October", "November", "December"}
> 	 set theYYYY to (text item 4 of theDateTime)
> 	 repeat with i from 1 to (count of theMonths)
> 		 if ((text item 2 of theDateTime) =
> (item i of theMonths)) then
> 			 set theMM to i as string
> 			 exit repeat
> 		 end if
> 	 end repeat
> 	 if ((count of theMM) < 2) then set theMM to
> ("0" & theMM)
> 	 set theDD to text 1 thru -2 of (text item 3 of
> theDateTime)
> 	 if ((count of theDD) < 2) then set theDD to
> ("0" & theDD)
> 	 set theTime to (text item 5 of theDateTime)
> 	 set theDay to text 1 thru -2 of (text item 1 of
> theDateTime)
> 	 set AppleScript's text item delimiters to oldDelimiter
> 	 if (theOption = "date") then
> 		 set theReturn to (theYYYY & "-" & theMM
> & "-" & theDD)
> 	 else if (theOption = "time") then
> 		 set theReturn to (theYYYY & "-" & theMM
> & "-" & theDD & "T" & theTime & ",0")
> 	 else
> 		 set theReturn to (theYYYY & "-" & theMM
> & "-" & theDD & " (" & theDay & ")")
> 	 end if
> 	 return theReturn
>  on error
> 	 return -1
>  end try
> end isoDateTime
> --------------------------------------------------------------
> ----------
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
> Printer at Myinks.com. Free s/h on orders $50 or more to the
> US & Canada. http://www.c1tracking.com/l.asp?cid=5511
> http://us.click.yahoo.com/sO0ANB/LIdGAA/ySSFAA/1U_rlB/TM
> --------------------------------------------------------------
> -------~->
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>

In the message "ISO 8601 Function in Perl?", dated 2003-08-04, Prof.
Simon Sunatori wrote:

>I am wondering if there are any pre-written [Perl] date/time
>functions (e.g., localtime(), timelocal(), etc.) which conform to
>ISO 8601.

    Jukka "Yukka" Korpela's terrific Web page on ISO 8601 provides
sample code in various languages, including Perl:

    "Info on ISO 8601, the date and time representation standard"
    http://www.cs.tut.fi/~jkorpela/iso8601.html

    Here's Jukka's example code in Perl "for getting the current date
and time and writing it in UTC":

>($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
>   gmtime(time);
>$t = sprintf "%4d-%02d-%02dT%02d:%02dZ\n",
>   1900+$year,$mon+1,$mday,$hour,$min;
>print $t;

    If you wish to work with the local time, rather than UTC, you can likely:

    - Substitute localtime() for gmtime().

    - Remove the trailing "Z" from the end of the string
      following "sprintf".

    To generate an unambiguous representation of the local time, you
would need to also add an ISO 8601-confirming representation of the
local offset from UTC to the end of the time string.

    If you wish to learn more about the built-in functions and various
add-on modules (libraries) available for working with dates and times
in Perl -- some of the latter quite extensive in their functionality
-- the following article is a great starting place:

    Dave Rolsky
    "The Many Dates and Times of Perl"
    O'Reilly Perl.com, March 13, 2003
    http://www.perl.com/pub/a/2003/03/13/datetime.html

    Near the end of this article, Dave also mentions his own suite of
date and time modules, which are ultimately intended to be
comprehensive.  You can view archives of the discussions about these
libraries at:

    http://archive.develooper.com/datetime@perl.org/

    (The hostname "develooper" above is spelled correctly :-)

Aron Roberts  Workstation Software Support Group . 221 Evans Hall
                University of California, Berkeley, CA 94720-3808 USA
                aron@... . +1 510-642-5974 . fax 510-643-5385

In the message "Re: ISO 8601 Function in Perl?", dated 2003-08-05,
Aron Roberts wrote:

>   If you wish to learn more about the built-in functions and various
>add-on modules (libraries) available for working with dates and
>times in Perl -- some of the latter quite extensive in their
>functionality -- the following article is a great starting place:
>
>   Dave Rolsky
>   "The Many Dates and Times of Perl"
>   O'Reilly Perl.com, March 13, 2003
>   http://www.perl.com/pub/a/2003/03/13/datetime.html
>
>   Near the end of this article, Dave also mentions his own suite of
>date and time modules, which are ultimately intended to be
>comprehensive.

    Since writing this, I've come across the home page for the Perl
"DateTime Project Modules":

    http://datetime.perl.org/

    A correction or clarification to the last sentence of my previous
posting above:  the FAQ and the list of available modules on this
site makes it evident that this is a community effort with many
contributors.  Dave Rolsky initiated the project and participates
actively in its work, as well as writing or co-writing nearly all of
its base modules.

Aron Roberts  Workstation Software Support Group . 221 Evans Hall
                University of California, Berkeley, CA 94720-3808 USA
                aron@... . +1 510-642-5974 . fax 510-643-5385

Mike Morris wrote:
>
> See http://datetime.perl.org/modules.html.
>
> If there's such a thing, I'd expect it to be there.
>
> There is a "DateTime::Format::ISO8601" Modules that "Parses ISO8601
> formats", but not sure about the other way..

Aron Roberts wrote:
>
>    Here's Jukka's example code in Perl "for getting the current date
> and time and writing it in UTC":

In order to generate a Monthly Calendar, I need to extract the day of
the week.  I looked around and found function time2iso() in the help
documentation.  However, it does not work in MacPerl 5.6.

   use HTTP::Date;
   print time2iso(time),"\n"; # outputs:
   # Undefined subroutine &main::time2iso called.

There is no module "DateTime::Format::ISO8601" in MacPerl 5.6, either.
Therefore, I picked function timelocal() and used Jukka's example
code.  With this, I do not need function POSIX::strftime().

   use Time::Local;
   my ($sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst) =
localtime(timelocal(0,0,0,1,($MM-1),($YYYY)));
   print sprintf("%4d-%02d-%02dT%02d:%02d:%02d,0", ($year + 1900),
($mon + 1), $mday, $hour, $min, $sec);

It has come to my attention that element "$wday" from PERL function
localtime() supports only years from 1954 to 2039, while AppleScript
function "date" supports the full Gregorian Calendar from 1582 to 3999.

* AppleScript | http://WWW.HyperInfo.CA/~HyperInfo.CA/Calendar.html
* PERL        | http://WWW.HyperInfo.CA/~HyperInfo.CA/Calendarr.html

The problem does not appear to be platform-specific or
version-specific.  I hope that "The Perl DateTime Project" will
address the localtime() issue...

Thank you very much for your attention.
Merci de votre attention.

Prof. Simon Sunatori, P.Eng./ing., M.Eng. (Engineering Physics), F.N.A.
President & Chief Executive Officer
HyperInfo Canada Inc.
--
Simon Sunatori      <http://WWW.HyperInfo.CA/~GS.Sunatori@HyperInfo.CA/>
65, des Parulines   <mailto:GS.Sunatori@...>
Gatineau (Quebec)   <telephone:+1-819-595-9210>
CANADA  J9A 1Z4     <facsimile:+1-425-984-7292>

Hi,

My suggestion would be to have at least a "pure ISO 8601" mode that conforms
exactly and then offer the forms that you think are more natural or popular as
options or alternatives so you satisfy both worlds.
I don't think the ISO community will complain unless you misrepresent formats
that are close to 8601, but not defined in 8601, as 8601 conformant. It might
help to warn your users that the 8601 format is best for data interchange and
the non 8601 variations are (perhaps) better for readability.

That's my 2 cents. But check with your (potential) user community if possible.

hth
tex

hjwoudenberg@... wrote:
>
> In a message dated 8/13/2003 5:25:01 PM Central Daylight Time, HJWOUDENBERG
> writes:
> Should be with blank before time
>
> > to = "Wednesday, August 2003-08-13 18:00:00+01:00 CEST"
>
> Subject: To Tex Texin
> Date: Wed, 13 Aug 2003 18:25:01 EDT
> From: HJWOUDENBERG@...
>
> My date and time conversion for anywhere in the world to anywhere in the
> world is just about completed.
>
> I support the ISO to the letter, but would like you advice about some common
> practices
>
> The ISO to the letter requires the "T" as the designator for time:
>
>        No zero suppression.
>        No names of day or month
>        Does do not permit truncation.
>        Only permits reduced precision on time.
>
>        It supports all combinations of date, time, fraction of time
> (hours,minutes,seconds[ fraction of days]),and Coordinate Universal Time
> offset and conversion for calendar dates, ordinal dates and week-dates.
>        It does not support Time Intervals (As you have pointed out the
> problems).
>
> The general practices supports:
>        'That the "T" is replace with a blank.
>        The name of the day and month can be prefixed to the date.
>        The text abbreviation for the time zone may be suffixed after the
> offset.
>
> Tex, you know the ISO community.  How much criticism can I expect?  This
> general practices are the real world, how do you think they should be
> handled?  Should I say these are not ISO dates?  The market wants these
> features.
>
> Examples of the use of the function (.fr  is ISO two letter code for France)
>   to = ADT(.fr:2003-08-13T12:00:00-05:00)
> (;CEST is Central Eruopean Summer Time)
>   to = ADT(;CET:2003-08-13T12:00:00-05:00)
>
> to=  "2003-08-13T18:00:00+01:00"
>
> to = ADT(*I&=.fr|L|!TZA:2003-08-13T12:00:00-05:00)
>
> to = "Wednesday, August 2003-08-13T18:00:00+01:00 CEST"

--
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:Tex@...
Xen Master                          http://www.i18nGuy.com

XenCraft 	            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------

The human-readable numeric formats should be:

2000-06-14T23:59:59Z or 2000-06-14T19:59:59-04:00
2000-06-14 23:59:59 (UTC) or 2000-06-14 19:59:59 (UTC-04:00)

The latter should be default and the former should be for the
internal code of programs.

The example with "Wednesday, August 2003-08-13T18:00:00+01:00 CEST"
isn't a very good example as the month is in two places and can
confuse a reader.. Something like "2003-08-13 (Wed) 18:00:00
(UTC+01:00)" would work much better. The "1999/12/31 (Friday)
23:59:59" format has been in use in China & Japan for a LONG time
so, it may be a good alternative. Modernising it to "1999-12-31
(Fri) 23:59:59" may be the best bet. For worded longhand dates in
English, something like "Saturday, 1 January 2000" (used in the UK)
or "2000 January 1 (Saturday)" (used in the Chinese, Hangul &
Japanese languages for thousands of years and by astronomers in the
form of "1999 Dec 31.ddd..." (decimal part of day) for a few
centuries) would work well.

I hope any of this helped...

--- In ISO8601@yahoogroups.com, Tex Texin <tex@i...> wrote:
> Hi,
>
> My suggestion would be to have at least a "pure ISO 8601" mode
that conforms
> exactly and then offer the forms that you think are more natural
or popular as
> options or alternatives so you satisfy both worlds.
> I don't think the ISO community will complain unless you
misrepresent formats
> that are close to 8601, but not defined in 8601, as 8601
conformant. It might
> help to warn your users that the 8601 format is best for data
interchange and
> the non 8601 variations are (perhaps) better for readability.
>
> That's my 2 cents. But check with your (potential) user community
if possible.
>
> hth
> tex
>
> hjwoudenberg@a... wrote:
> >
> > In a message dated 8/13/2003 5:25:01 PM Central Daylight Time,
HJWOUDENBERG
> > writes:
> > Should be with blank before time
> >
> > > to = "Wednesday, August 2003-08-13 18:00:00+01:00 CEST"
> >
> > Subject: To Tex Texin
> > Date: Wed, 13 Aug 2003 18:25:01 EDT
> > From: HJWOUDENBERG@a...
> >
> > My date and time conversion for anywhere in the world to
anywhere in the
> > world is just about completed.
> >
> > I support the ISO to the letter, but would like you advice about
some common
> > practices
> >
> > The ISO to the letter requires the "T" as the designator for
time:
> >
> >        No zero suppression.
> >        No names of day or month
> >        Does do not permit truncation.
> >        Only permits reduced precision on time.
> >
> >        It supports all combinations of date, time, fraction of
time
> > (hours,minutes,seconds[ fraction of days]),and Coordinate
Universal Time
> > offset and conversion for calendar dates, ordinal dates and week-
dates.
> >        It does not support Time Intervals (As you have pointed
out the
> > problems).
> >
> > The general practices supports:
> >        'That the "T" is replace with a blank.
> >        The name of the day and month can be prefixed to the date.
> >        The text abbreviation for the time zone may be suffixed
after the
> > offset.
> >
> > Tex, you know the ISO community.  How much criticism can I
expect?  This
> > general practices are the real world, how do you think they
should be
> > handled?  Should I say these are not ISO dates?  The market
wants these
> > features.
> >
> > Examples of the use of the function (.fr  is ISO two letter code
for France)
> >   to = ADT(.fr:2003-08-13T12:00:00-05:00)
> > (;CEST is Central Eruopean Summer Time)
> >   to = ADT(;CET:2003-08-13T12:00:00-05:00)
> >
> > to=  "2003-08-13T18:00:00+01:00"
> >
> > to = ADT(*I&=.fr|L|!TZA:2003-08-13T12:00:00-05:00)
> >
> > to = "Wednesday, August 2003-08-13T18:00:00+01:00 CEST"
>
> --
> -------------------------------------------------------------
> Tex Texin   cell: +1 781 789 1898   mailto:Tex@X...
> Xen Master                          http://www.i18nGuy.com
>
> XenCraft 	            http://www.XenCraft.com
> Making e-Business Work Around the World
> -------------------------------------------------------------

Hi,

I am not clear on what you are saying in the latter half of your mail.

I agree that text names included with the date can be confusing.
For some users they are reassuring however.

When you say:

> or "2000 January 1 (Saturday)" (used in the Chinese, Hangul &
> Japanese languages for thousands of years

I have to question this, since Gregorian calendar is relatively recent,
adoption of English is even more recent, and lunar calendars were used going
back millenia in China, but not so far back in Japan.

Here is a page on Chinese calendar history:
http://webexhibits.org/calendars/calendar-chinese.html

and for Japanese:
http://www.ndl.go.jp/koyomi/e/history/02_index1.html

Maybe you are referring to the date format, independent of the calendar in use?

As for using English, it is acceptable in HK, and certainly is used in the
other markets, but in general you will improve the marketability of your
software if you use the native language.

I would also recommend using the native characters for month, day and year as
separators, as is the custom, where appropriate. For columns of dates or
reports/screens where space is at a premium, using just the slash or hyphen
separator characters is acceptable.

However, this is cultural formating, not data interchange, and we are now far
afield from 8601 which is the locus of this list.

tex


ali0917 wrote:
>
> The human-readable numeric formats should be:
>
> 2000-06-14T23:59:59Z or 2000-06-14T19:59:59-04:00
> 2000-06-14 23:59:59 (UTC) or 2000-06-14 19:59:59 (UTC-04:00)
>
> The latter should be default and the former should be for the
> internal code of programs.
>
> The example with "Wednesday, August 2003-08-13T18:00:00+01:00 CEST"
> isn't a very good example as the month is in two places and can
> confuse a reader.. Something like "2003-08-13 (Wed) 18:00:00
> (UTC+01:00)" would work much better. The "1999/12/31 (Friday)
> 23:59:59" format has been in use in China & Japan for a LONG time
> so, it may be a good alternative. Modernising it to "1999-12-31
> (Fri) 23:59:59" may be the best bet. For worded longhand dates in
> English, something like "Saturday, 1 January 2000" (used in the UK)
> or "2000 January 1 (Saturday)" (used in the Chinese, Hangul &
> Japanese languages for thousands of years and by astronomers in the
> form of "1999 Dec 31.ddd..." (decimal part of day) for a few
> centuries) would work well.
>
> I hope any of this helped...
>
> --- In ISO8601@yahoogroups.com, Tex Texin <tex@i...> wrote:
> > Hi,
> >
> > My suggestion would be to have at least a "pure ISO 8601" mode
> that conforms
> > exactly and then offer the forms that you think are more natural
> or popular as
> > options or alternatives so you satisfy both worlds.
> > I don't think the ISO community will complain unless you
> misrepresent formats
> > that are close to 8601, but not defined in 8601, as 8601
> conformant. It might
> > help to warn your users that the 8601 format is best for data
> interchange and
> > the non 8601 variations are (perhaps) better for readability.
> >
> > That's my 2 cents. But check with your (potential) user community
> if possible.
> >
> > hth
> > tex
> >
> > hjwoudenberg@a... wrote:
> > >
> > > In a message dated 8/13/2003 5:25:01 PM Central Daylight Time,
> HJWOUDENBERG
> > > writes:
> > > Should be with blank before time
> > >
> > > > to = "Wednesday, August 2003-08-13 18:00:00+01:00 CEST"
> > >
> > > Subject: To Tex Texin
> > > Date: Wed, 13 Aug 2003 18:25:01 EDT
> > > From: HJWOUDENBERG@a...
> > >
> > > My date and time conversion for anywhere in the world to
> anywhere in the
> > > world is just about completed.
> > >
> > > I support the ISO to the letter, but would like you advice about
> some common
> > > practices
> > >
> > > The ISO to the letter requires the "T" as the designator for
> time:
> > >
> > >        No zero suppression.
> > >        No names of day or month
> > >        Does do not permit truncation.
> > >        Only permits reduced precision on time.
> > >
> > >        It supports all combinations of date, time, fraction of
> time
> > > (hours,minutes,seconds[ fraction of days]),and Coordinate
> Universal Time
> > > offset and conversion for calendar dates, ordinal dates and week-
> dates.
> > >        It does not support Time Intervals (As you have pointed
> out the
> > > problems).
> > >
> > > The general practices supports:
> > >        'That the "T" is replace with a blank.
> > >        The name of the day and month can be prefixed to the date.
> > >        The text abbreviation for the time zone may be suffixed
> after the
> > > offset.
> > >
> > > Tex, you know the ISO community.  How much criticism can I
> expect?  This
> > > general practices are the real world, how do you think they
> should be
> > > handled?  Should I say these are not ISO dates?  The market
> wants these
> > > features.
> > >
> > > Examples of the use of the function (.fr  is ISO two letter code
> for France)
> > >   to = ADT(.fr:2003-08-13T12:00:00-05:00)
> > > (;CEST is Central Eruopean Summer Time)
> > >   to = ADT(;CET:2003-08-13T12:00:00-05:00)
> > >
> > > to=  "2003-08-13T18:00:00+01:00"
> > >
> > > to = ADT(*I&=.fr|L|!TZA:2003-08-13T12:00:00-05:00)
> > >
> > > to = "Wednesday, August 2003-08-13T18:00:00+01:00 CEST"
> >
> > --
> > -------------------------------------------------------------
> > Tex Texin   cell: +1 781 789 1898   mailto:Tex@X...
> > Xen Master                          http://www.i18nGuy.com
> >
> > XenCraft                          http://www.XenCraft.com
> > Making e-Business Work Around the World
> > -------------------------------------------------------------
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

--
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:Tex@...
Xen Master                          http://www.i18nGuy.com

XenCraft 	            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 2003-09-01

----- Original Message -----

From: Adam NGUYEN

To: ISO8601@yahoogroups.com

Sent: 2003 09  03 Wednesday 02:17

Subject: Re: [ISO8601] Re: Pure ISO 8601 or varied for popular formats

        I was referring to just the date format, not the actual calendar in use. The Chinese, Japanese, and Koreans have been using the year-month-day date order for a VERY LONG time. Just ask Justin JIH ( his site is at http://www.geocities.com/jusjih ). He'll tell you the same thing.

        What I really wonder is how did the US all of a sudden just start using month-day-year order in their dates ("Sunday, January 9, 2000" & "01/09/2000" are examples of written dates. "Sunday, January the ninth, two thousand" & "Sunday, January ninth, two thousand" are examples of the speech used in the US). The US' official language is English, which has always used day-month-year in a written date order in English-speaking countries before the US somehow, "came up with", the month-day-year order. Where did they get this idea from? Maybe they always have written their dates in month-day order and when they needed to put the year in, they just slapped it on as something extra?

        What's accepted in HK? A year-month-day longhand date in English like "2000 January 1 (Saturday)"?

==========================================================

I have an educated guess as to why we Americans got stuck with such an ass backward system.  The first clue is the English language, which used to express dates based on Christian religious traditions of yore, and - by the nature of western European languages - using possessive mode.  First of April, in the Year of the Lord Seventeen Hundred and Sixty-nine.

 

In numbers,  1st of April, 1769 AD.  The revolutionary American governments wanted to break away from anything that was British, and switched the order around*.  July fourth, 1955.  The growing economic prowess and world leader ambitions would not allow the United States to give up its traditions, even when it meant falling behind Canada, Mexico and the rest of the world.  Hence the US is the only major industrialized nation that has made no effort to subscribe to the SI (Systeme Internationale),  the modernized metric system, although it has been a legal measurement system there for over a century.  The US also starts the week with the weekend, and the first hour of the day is 12, after midnight, instead of zero hour.  You go figure!

 

Hong Kong is still plugging the British system, but slowly the ISO 8601 system and SI are seeping in.  The cars are still driven on the left side of the highways, the flats are still sold by area of square feet.  Hong Kong has about 45 years to join the standards set by the Mainland Chinese.  However, economic considerations will force Hong Kong and Macao to modernize much sooner than that.

---

*A similar madness is what the Taiwan government is cooking up by developing a system for Romanization of Chinese characters, one that is different from the decades-old Pin-yin Chinese system.  Their reason for being different: to spite Beijing. It is a blatant politicizing of a scientific issue.  Never mind the difficulties of those who are trying to tackle the Mandarin language and now have to learn two different methods of reading Chinese characters printed in western letters.

---

BUDAI  A. E.  —  Xinzhu City  Taiwan    email: bandi@...

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 2003-09-01

Well, it's possible to write and say a date out in numeric form in
year-month-day format, as it has been done with ISO's year-week-day
format. Does this sound correct?: "Year 1999, Week 52, Day 6"

How about this?: "(Year) 2000 (two thousand), Month 01 (one), Day 01
(one)"?
And this?: "(Year) 2000 (two thousand), Day 001 (one)"
This?: "(Year) 2000, January 01 (one)"

Are they all correct or should something be changed? Are dates in
English commonly said in year-month-day format or day-month-year
format? If they are said in year-month-day, what is said? If it's
day-month-year, an example date in a sentence would be "Today is the
third of September, two thousand [and] three.", right? Something
else interesting to note is the Windows XP Regional settings
have "Wednesday, 3 September, 2003" as the long date and "3/9/2003"
(D/M/YYYY) as the short date, instead of YYYY-MM-DD as the short
date and something like "2003 September 3 (Wednesday)".

--- In ISO8601@yahoogroups.com, "Budai, Andrew" <bandi@m...> wrote:
> An American reply from Asia.
[...]
>   I have an educated guess as to why we Americans got stuck with
such an ass backward system.  The first clue is the English
language, which used to express dates based on Christian religious
traditions of yore, and - by the nature of western European
languages - using possessive mode.  First of April, in the Year of
the Lord Seventeen Hundred and Sixty-nine.
>
>   In numbers,  1st of April, 1769 AD.  The revolutionary American
governments wanted to break away from anything that was British, and
switched the order around*.  July fourth, 1955.  The growing
economic prowess and world leader ambitions would not allow the
United States to give up its traditions, even when it meant falling
behind Canada, Mexico and the rest of the world.  Hence the US is
the only major industrialized nation that has made no effort to
subscribe to the SI (Systeme Internationale),  the modernized metric
system, although it has been a legal measurement system there for
over a century.  The US also starts the week with the weekend, and
the first hour of the day is 12, after midnight, instead of zero
hour.  You go figure!
>
>   Hong Kong is still plugging the British system, but slowly the
ISO 8601 system and SI are seeping in.  The cars are still driven on
the left side of the highways, the flats are still sold by area of
square feet.  Hong Kong has about 45 years to join the standards set
by the Mainland Chinese.  However, economic considerations will
force Hong Kong and Macao to modernize much sooner than that.
>
> -------------------------------------------------------------------
-----------
>
>   *A similar madness is what the Taiwan government is cooking up
by developing a system for Romanization of Chinese characters, one
that is different from the decades-old Pin-yin Chinese system.
Their reason for being different: to spite Beijing. It is a blatant
politicizing of a scientific issue.  Never mind the difficulties of
those who are trying to tackle the Mandarin language and now have to
learn two different methods of reading Chinese characters printed in
western letters.
>
> -------------------------------------------------------------------
-----------
>
>   BUDAI  A. E.  —  Xinzhu City  Taiwan    email: bandi@m...
> -------------------------------------------------------------------
-----------

Enter your vote today!  A new poll has been created for the
ISO8601 group:

Do you prefer to put a leading zero in
front of a day number within a month,
as in "01 January 2000", "2000 January
01", and "January 01, 2000" or do you
prefer to use no leading zero in front
of a day number within a month,
like "1 January 2000", "2000 January
1", and "January 1, 2000"? Explain why
or why not if you wish.

   o Yes (like "2000 January 01")
   o No (like "2000 January 1")


To vote, please visit the following web page:

http://groups.yahoo.com/group/ISO8601/surveys?id=1132955

Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the Yahoo! Groups
web site listed above.

Thanks!

Did not see a place on the voting form for a "why", so here it is.

     Column
     Alignment

When printing dates in column format, keeping column alignment makes
it much easier to scan the dates. At least it does for me.

We don't care what you do in a non-ISO8601 format! This group is only
concerned with ISO8601 compliant formats!

At 2003-09-04 01:38 +0000, ISO8601@yahoogroups.com wrote:
>Do you prefer to put a leading zero in
>front of a day number within a month,
>[...]
>Explain why
>or why not if you wish.

I voted yes as that is all that ISO 8601 permits.

But where was the chance to add my explanation?  I would not have
registered any vote if I'd realized that this was unavailable.

That poll is off topic for this group in any case.

--
Pete Forman                -./\.-  Disclaimer: This post is originated
WesternGeco                  -./\.-   by myself and does not represent
pete.forman@...    -./\.-   opinion of Schlumberger, Baker
http://petef.port5.com           -./\.-   Hughes or their divisions.

If you have any links to my
http://www.geocities.com/jusjih/measure/iso8601.html or
http://www.geocities.com/jusjih/iso8601.html , it is now
http://www.geocities.com/jusjih/num-iso8601.html#iso8601 with major
revision, but redirection is available. I have dropped most paragraphs of
the former English essay in favour of trilingual lay-out.

     ISO 8601 uses a solidus (/) for time-intervals, but it recognizes that
certain application areas use a double hyphen (--). What I wonder is if it
will be better to use a right-ward arrow, such as:

"Swedish Minister for Foreign Affairs Anna LINDH (1957-06-19->2003-09-11)
died at 2003-09-11T05:29+02:00 after a knife attacked at about
2003-09-10T16+02."

     It appears that the links at http://groups.yahoo.com/group/ISO8601/links
mostly created by g1smd_amsat_org are out of maintenance, so I, as a
moderator in another Y! Group, would like to suggest some improvements.

     Coming up in the future: Inspired by http://www.halisa.net/cpt/d/ , I
will probably add similar calendars in my page in my lay-out. Under "Ordinal
date", I have added the day numbers in a year.

Justin

Justin - a 'greater-than' sign (right-ward arrow) would likely cause
parser errors in XML applications. It is a reserved character for tags
in the markup.
--
Jon Sears

jus168jih@... wrote:

>     If you have any links to my
> http://www.geocities.com/jusjih/measure/iso8601.html or
> http://www.geocities.com/jusjih/iso8601.html , it is now
> http://www.geocities.com/jusjih/num-iso8601.html#iso8601 with major
> revision, but redirection is available. I have dropped most paragraphs of
> the former English essay in favour of trilingual lay-out.
>
>     ISO 8601 uses a solidus (/) for time-intervals, but it recognizes that
> certain application areas use a double hyphen (--). What I wonder is if it
> will be better to use a right-ward arrow, such as:
>
> "Swedish Minister for Foreign Affairs Anna LINDH (1957-06-19->2003-09-11)
> died at 2003-09-11T05:29+02:00 after a knife attacked at about
> 2003-09-10T16+02."
>
>     It appears that the links at http://groups.yahoo.com/group/ISO8601/links
> mostly created by g1smd_amsat_org are out of maintenance, so I, as a
> moderator in another Y! Group, would like to suggest some improvements.
>
>     Coming up in the future: Inspired by http://www.halisa.net/cpt/d/ , I
> will probably add similar calendars in my page in my lay-out. Under "Ordinal
> date", I have added the day numbers in a year.
>
> Justin
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 2003-09-01

Adding the rightward arrow now might interfere with some existing applications
that attribute meaning to the right angle bracket.

As it would be work to support a third form of separator, and as the standard
is for date interchange, what is the benefit of a rather minor improvement in
visualization?

What is the problem that is being solved?

tex

jus168jih@... wrote:

> ...
>     ISO 8601 uses a solidus (/) for time-intervals, but it recognizes that
> certain application areas use a double hyphen (--).

Thanks for pointing that out.  I hadn't noticed this paragraph before.
What it says (at the end of section 5.5.2 in the draft 8601:2000 I have
to hand):

# NOTE  In certain application areas a double hyphen is used as a
# separator instead of a solidus.

This is horrible.  It is not made clear whether the application areas
referred to are considered to be conforming to the standard or not.
Perhaps this is another of those assertions which should be prefixed
with "by mutual agreement".

Also, it doesn't mix well with the truncated representations.  E.g.,
using the truncated representation for a specific day in an implied
month (5.2.1.3 f) you might write the three days starting today as:

   2003-09-17/---19

which would become:

   2003-09-17-----19

which looks a bit silly to me.

I think it would be better to avoid the double hyphen as a separator
unless it is actually present in legacy data.

jus168jih@... further wrote:

> What I wonder is if it
> will be better to use a right-ward arrow
> ...

Right arrow would make some sense in the case where a time-interval is
specified by a start and an end.  However, it would look a bit odd when
a start and a duration or, particularly, a duration and an end are used:

   2003-09-17T18:00Z->P2H

for the two hour period starting at six o'clock this evening or,

   P6M->2003-09

for the six months ending this month.

Overall, the only problem with using solidus for time intervals that I
can see is that it clashes a bit with the date separator character
used in many non-ISO 8601 date formats.  Applications which are using
ISO 8601 for the expression of time intervals are probably well
enough controlled that no confusion would arise.  Therefore, I really
don't see any good reason to make this change.

Ed.

On 2003-09-16 09:53:37 -0400, Jon Sears wrote:
> Justin - a 'greater-than' sign (right-ward arrow) would likely cause
> parser errors in XML applications. It is a reserved character for tags
> in the markup.

But it can (and must) be encoded as ">", so there would be no
problems in practice.

--
Vincent Lefèvre <vincent@...> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

At 2003-09-17 11:57 +0200, Vincent Lefevre wrote:
>On 2003-09-16 09:53:37 -0400, Jon Sears wrote:
> > Justin - a 'greater-than' sign (right-ward arrow) would likely cause
> > parser errors in XML applications. It is a reserved character for tags
> > in the markup.
>
>But it can (and must) be encoded as ">", so there would be no
>problems in practice.

Sorry to be picky but that should be "may" not "must" in this
context.  Only < and & must be escaped.  The only time that > must be
escaped is when it might be confused with the end of a CDATA section.

http://www.w3.org/TR/REC-xml#syntax

--
Pete Forman                -./\.-  Disclaimer: This post is originated
WesternGeco                  -./\.-   by myself and does not represent
pete.forman@...    -./\.-   opinion of Schlumberger, Baker
http://petef.port5.com           -./\.-   Hughes or their divisions.

--- In ISO8601@yahoogroups.com, Pete Forman <pete.forman@w...> wrote:
> At 2003-09-17 11:57 +0200, Vincent Lefevre wrote:
> >On 2003-09-16 09:53:37 -0400, Jon Sears wrote:
> > > Justin - a 'greater-than' sign (right-ward arrow) would likely
cause
> > > parser errors in XML applications. It is a reserved character
for tags
> > > in the markup.
> >
> >But it can (and must) be encoded as ">", so there would be no
> >problems in practice.
>
> Sorry to be picky but that should be "may" not "must" in this
> context.  Only < and & must be escaped.  The only time that > must
be
> escaped is when it might be confused with the end of a CDATA
section.
>
> http://www.w3.org/TR/REC-xml#syntax

And that would only apply when putting an ISO8601 date on a Web page,
rather than a data file. And in such cases I would suggest using a
more human-friendly format rather than ISO8601 anyway.
Such as something like: "The conference will begin at 10:00 on Friday
2003-09-19 and run through 20:00 on Sunday 2003-09-21".

ISO8601 is for information interchange (generally between computers),
the Web is to relate information to humans.
Also remember that some of the separators, like the hyphen (-) in the
date is not required, and even frowned-upon (if memory serves).

>    From: Adam NGUYEN <adam917@...>
>
>          Well, the double-hyphen is part of the the standard and looks so
> similar to what has been traditionally used (single hyphen) for time
> intervals. On some fonts, the two hyphens appear to run into each other
> like it was a single longer hyphen.

In China, a tilde (~) may also be used for this purpose.

>          Out of curiosity, which Yahoo Group do you moderate?

http://groups.yahoo.com/group/anti-conscription/ (open membership) and
http://groups.yahoo.com/group/anconnet/ (RESTRICTED membership)
(with more than a year of experience moderating the groups)



>As it would be work to support a third form of separator, and as the standard
>is for date interchange, what is the benefit of a rather minor improvement in
>visualization?
>
>What is the problem that is being solved?
>
>tex

When ISO 8601 was revised around 2000, some minor improvement DID exist.
http://dsweb.dial.pipex.com/town/square/xta78/ISO8601/8601v03.pdf contains a
lot of alterations. Frankly, many people don't readily recognize a solidus
as a separator for time-intervals. I have talked with some others saying
that something like 1957-06-19/2003-09-11 could be misinterpreted as TWO
SEPARATE dates.



>    From: Ed Davies <edavies@...>
> Subject: Re: My revised page of numbers and ISO 8601 (links in the group need
updates)
>
> jus168jih@... wrote:
>
>> ...
>>     ISO 8601 uses a solidus (/) for time-intervals, but it recognizes that
>> certain application areas use a double hyphen (--).
>
> Thanks for pointing that out.  I hadn't noticed this paragraph before.
> What it says (at the end of section 5.5.2 in the draft 8601:2000 I have
> to hand):
>
> # NOTE  In certain application areas a double hyphen is used as a
> # separator instead of a solidus.
>
> This is horrible.  It is not made clear whether the application areas
> referred to are considered to be conforming to the standard or not.
> Perhaps this is another of those assertions which should be prefixed
> with "by mutual agreement".

Without mutual agreement, even some things in ISO 8601 are not readily
understandable.

Justin

Justin,

Well I guess its possible that it could be considered 2 separate dates without
including the interval in between, it still seems to me you are refering to
(mis)interpretation by humans. Someone implementing a software program that
interchanges dates using ISO 8601 should take a look at the standard, which is
clear enough, and implement it accordingly. So there shouldn't be any problems
with interchange.

On the other hand, for the thousands of programmers that implement software,
adding a third interval variation means more code and more testing... Doesn't
really seem worth it. It can always be rendered on the screen differently
without violating the standard.


tex
jus168jih@... wrote:

> >
> >What is the problem that is being solved?
> >
> >tex
>
> When ISO 8601 was revised around 2000, some minor improvement DID exist.
> http://dsweb.dial.pipex.com/town/square/xta78/ISO8601/8601v03.pdf contains a
> lot of alterations. Frankly, many people don't readily recognize a solidus
> as a separator for time-intervals. I have talked with some others saying
> that something like 1957-06-19/2003-09-11 could be misinterpreted as TWO
> SEPARATE dates.
>