--- John Steele <johnmsteele@y...> wrote:
> I'm sure astronmers everywhere would have preferred Julian Days, ie
> 245 3461.500

Astronomers also use Gregorian dates, in year-month-day order, with
the fractional day added to the ordinal day of month.  For instance,
the standard epoch J2000.0 is often represented as 2000 January 1.5,
which would be 2000-01-01,5 in ISO format.  I can provide many
examples online.  Also, NASA and NORAD publish epoch dates of orbital
elements of artificial satellites as ordinal dates with fractional day
added, e.g. the same date is represented as 00001.50000000.  (Still
with two-digit year, unfortunately.)  It would make sense to
incorporate this practice by astronomers into ISO 8601.  Although the
month is usually spelled out or abbreviated, the month number is also
used sometime.  The ISO standard does cover decimal fractions of
hours, minutes and seconds, but not days.

I suppose that Julian Dates could be added to the ISO 8601 standard,
but that would seem unnecessary, since they are represented simply as
a single decimal number.  It would be a short section.  I think that
fractional day s are used by astronomers, instead of HMS, for ease in
calculations, including the converstion to/from JD/MJD.  Julian Days
and Julian Dates, as well as Modified Julian Dates, already are
covered by a standard, IAUGA XXIII Resolution B1.

And if anybody hasn't figured it out by now, April Fool!  I figured
that this group might get a kick out of it. :)

John

I've noticed quite often, that people & organisations try to go to the
new date standard, but do not understand, that it is more than just
the replacement of the "/" or "." with the "-".

Recent Examples:
- Retailers in Germany replace the former "DD.MM.YY" with "DD-MM-YY"
- Peugeout shows the date in our car as "DD-MM-YY"
- I've got a confirmation from DELL today(2005-04-14!!):
     . Service Tag: 1SPPK0J
     . Datum des Serviceauftrags: 14-04-05 (DD-MM-YY !!!)
     . Serviceauftrags #: ...

The last one made me think that something should be done right now.
That's why I joined your group.

Do you have any national contacts where problems like the above could
be addressed to?

Regards
Hubert

http://www.w3.org/TR/xmlschema-2/#isoformats

 

Anyone know why ISO-8601 has a year zero. 

 

Why does 8601 introduce a year 0?

To get to the other side!

Should software support it?

Yes. If you implement the standard, it should be a complete
implementation.
There is no reason not to implement it.
It simplifies calculations between dates in the standard's format.

With respect to conversions to julian or other calendars, it does not
harm, since those conversions need to take many things into account
already, such as the date the local government converted from julian to
gregorian, etc.
time zone and leap year practices...

Dealing with the addition of zero is trivial and at least constant
worldwide, compared to the other issues.

I would recommend we not trouble ourselves over these minor quibbles
with the standard.
Fixing the zero is not the problem and will neither accelerate or
decelerate the adoption of the standard.

More important to this group is what can be done to accelerate adoption
of the standard.

And I am not asking how can we change the standard to improve adoption.
I am asking what are the obstacles in the marketplace to its adoption
and how can we lower the barrier.



--
-------------------------------------------------------------
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
-------------------------------------------------------------

[2005-Jun-24]



Please do not quote large chunks of previous messages. There is no
need.  We have already seen the previous message (and they are all
archived at http://groups.yahoo.com/group/ISO8601/ forever).

If you do quote a small section of a previous message, then always
write your reply BELOW the quoted part.

Always delete all of the stuff from the original message that you are
not replying to. Keep it brief.

Ensure that the message title reflects whatever the message is about.
Never reply to a message and then change the subject without also
changing the message title itself.

Beware that any reply that you send out is automatically sent on to
everyone in the group. If your reply only needs to go back to one
person, then edit the destination so that it really only does go to
that one person.


ISO 8601 Moderators.

--- In ISO8601@yahoogroups.com, Tex Texin <tex@x> wrote:
> More important to this group is what can be done to accelerate
adoption
> of the standard.
>
> And I am not asking how can we change the standard to improve
adoption.
> I am asking what are the obstacles in the marketplace to its
adoption
> and how can we lower the barrier.

Agree, this topic is interesting. Here some hypothetical reasons and
statements about the slow adoption of ISO8601, which came into my
mind:

ISO8601 is not preferred by software
OR
ISO8601 is not preferred by the rest of the world
(probable reason: see above)

ISO8601 is not preferred because the standard is judged as weak
OR
Other notations are preferred because of tradition and history

date time is a data type and the notation is a matter of IO-format
==> we have not to worry about any standard notation
OR
date time can be part of any fixed, unchangeable text document

date time notation depends on national and/or language configurations
==> software users are tired to tackle with these configurations to
get ISO8601
OR
date time notation is independent of any other configuration
==> this would allow a default ISO8601 configuration

good software must support only one variant of ISO8601
==> software can concentrate on more important things
OR
good software must support all known date time notations of the world

software must reflect the preferences of the rest of the world
OR
software must prefer international standards

To which statements would you agree/disagree and why?

-- Klaus

Hi,

Your algorithm is the common way to calculate the last day of the month.

I am not sure if you are asking a question or not.

A date library should have such a function.

The internals are irrelevant to a user, so whether you are purist or
not, shouldn't matter as long as the results are the expected ones.

Are you asking what an ISO 8601 syntax would be to express:
a) The first day of the month of some date?
b) the last day of the month of some date?

tex

Frequently, I must get the last day of the month, 31,30,29, and 28

I have a function that allows me to set any element year, month, day,
hour, minute, second to a specified value.  I use this to set the day of
the month as "01".

     2004-02-15 to 2004-02-01

I use "P01M" to add one month to the date.

     2004-02-01 to 2004-03-01

I use "-P01D" to subtract one day from the date giving me the last day
of the previous month.

     2004-03-01 to 2004-02-29

I am ready to make a non ISO8601 duration "P=1D+1M-1D"

I would make another function which converts "P=1D+1M-1D" into three ISO
durations for those who want to be purist: "=P1D", "P1M" and "-P1D".
Some might say "=P1D" is not a proper ISO-8601 duration.  It should be
and  I am interested on how they can do this.

hjw

--- In ISO8601@yahoogroups.com, hjwoudenberg@a... wrote:

> I agree software must prefer international  standards.  Someday this
will
> happen
>
> I agree software must reflect the preferences of the rest of the
world until
> the rest of the world is ready to  change.
>

Herman, thanks for your comments, I think we have almost the same
opinion about this.

[...]
> ISO-8601 has deficiencies.  It must have the humility to fix  them
else
> everyone will have their exceptions.
>
> I get the feeling the ISO-8601 is cast in stone.

Yes, maybe this is a valid point as well. If more knowledgable persons
would be more happy with the standard, they would probably try harder
to spread the standard among others.

Tex, what is your opinion on the points I mentioned? Or have I
misunderstood something about what you would like to discuss here?

-- Klaus

hjw trolls:

XML is the big guns of today.
XML has endorsed ISO-8601 syntax
XML has endorsed ISO-8601 duration.
ICF (international components for UNICDE)  does not.
JAVA does not!.
Whore do you stand?

hjw


XML is important yes.
XML using ISO 8601 is a good thing.
ICU (not ICF) uses a binary data type for efficiency and that is a good
thing.
So does Java.
Both are capable of producing an ISO 8601 date format if needed and to
use for date interchange in text based environments.

Where I stand is I straddle standards and technologies, and I live quite
comfortably.
;-)

How about you?

Best regards,

Tex



--
-------------------------------------------------------------
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
-------------------------------------------------------------

hjwoudenberg said:

> Microsoft advocates. They want Microsoft date and time data type.

This doesn't make any sense at all. What would be the use of such a thing
in the context of a textual representation (which is what ISO8601 is
about)?

HJW:

Can you point us at some documents on the discussion you are referring
to?
We don't have any context for this.

From the original mail, I thought it was you objecting to Microsoft not
using ISO 8601 in their api.
tex


In a message dated 7/11/2005 1:04:52 P.M. Central Daylight Time,
fred.bone@... writes:

       This doesn't make any sense at all. What would be the use of such
a thing
       in the context of a textual representation (which is what ISO8601
is
       about)?

Good point, that means all binary integer dates are not good candidates.
XML and ISO-8601 are both textual in representation.  I wonder if the
group objecting understood this.

IERS announced in Bulletin C 30 (2005-07-04) that a leap second will be
introduced at the end of 2005. Following the leap second, TAI-UTC = 33
s.
ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat

This will be the first leap second since the end of 1998 and a chance
for any "real world" testing of leap second handling.

Cool, thanks John.


johnmsteele wrote:
>
> IERS announced in Bulletin C 30 (2005-07-04) that a leap second will be
> introduced at the end of 2005. Following the leap second, TAI-UTC = 33
> s.
> ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
>
> This will be the first leap second since the end of 1998 and a chance
> for any "real world" testing of leap second handling.
>
>
> Yahoo! Groups Links
>
>
>
>

--
-------------------------------------------------------------
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
-------------------------------------------------------------

On 15 Jul 2005 at 17:32, ISO8601@yahoogroups.com said:

> IERS announced in Bulletin C 30 (2005-07-04) that a leap second will be
> introduced at the end of 2005. Following the leap second, TAI-UTC = 33
> s.
> ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
>
> This will be the first leap second since the end of 1998 and a chance
> for any "real world" testing of leap second handling.
>

It might also be the last. Moves are afoot to redefine the relationship
between UTC and UT1. If accepted, then from 2007-12-21T00:00(*) UTC would
no longer be kept within 0.9s of UT1; the limit would become 1h, which
should see most of us out ...

(*) No, I don't know why this date was chosen.

It might also be the last. Moves are afoot to redefine the relationship
between UTC and UT1. If accepted, then from 2007-12-21T00:00(*) UTC would
no longer be kept within 0.9s of UT1; the limit would become 1h, which
should see most of us out ...
(*) No, I don't know why this date was chosen.

2005-11-08/11: ITU-R WP7A, Geneva

The next meeting of ITU-R Working Party 7A has no agenda yet. It is becoming clear that the presentations and events at this meeting will be relevant to changes in ITU-R TF.460-6. This will almost certainly be the meeting which makes the final internal recommendation to the ITU-R regarding the fate of leap seconds in UTC.

2007-10-08/11-02: ITU-R World Radiocommunication Conference (WRC-07)

Changes to ITU-R recommendations might be made at this meeting. As indicated above it appears that efforts to revise ITU-R TF.460-6 are being made in preparation for submission to this conference for approval. Note that the effective date of the end of leap seconds apparently being proposed by the United States is 2007-12-21 which is less than two months after the conference.