## Fraction of days, ISO-8601 2005

Expand Messages
• When I round trip a date and time to fraction of days, the round trip is only approximate the same. Most of my times convert to repeating decimal fractions of
Message 1 of 8 , Sep 12 11:40 PM
When I round trip a date and time to fraction of days, the round trip is only approximate the same.

Most of my times convert to repeating decimal fractions of days.  Therefore when they are convert back to hours, minutes, seconds the time is only approximately the same, especially if the time has fractions of seconds.

Does anyone have a trick to avoid this problem?

hjw
• You could multiply the hrs/min/sec out of the equation, effectively expressing your time as a decimal fraction of seconds (the multiplier is 60*60*24 = 86400).
Message 2 of 8 , Sep 13 12:07 AM
You could multiply the hrs/min/sec out of the equation, effectively expressing your time as a decimal fraction of seconds (the multiplier is 60*60*24 = 86400).
Other than that, I'm afraid there is no 'clean' way to do this, since you cannot represent 1/24 comfortably as a decimal fraction, let alone 1/1440 or 1/86400.

hjwoudenberg@... wrote:
When I round trip a date and time to fraction of days, the round trip is only approximate the same.

Most of my times convert to repeating decimal fractions of days.  Therefore when they are convert back to hours, minutes, seconds the time is only approximately the same, especially if the time has fractions of seconds.

Does anyone have a trick to avoid this problem?

hjw
• I would consider using just seconds. As time units are largely based off fractions like 1/24 & 1/60, you will definitely get repeating decimals when doing
Message 3 of 8 , Sep 13 1:08 PM
I would consider using just seconds. As time units are largely based
off fractions like 1/24 & 1/60, you will definitely get repeating
decimals when doing calculations using converted decimal values. Using
just days & seconds can get rid of this issue a lot, but not
completely (as a day is 86400 seconds long and one second is 1/86400
of a day.

If you use a scientific calculator, you can switch it into angular
degrees/minutes/seconds mode and pretend that the degrees are hours.
This can get you accurate values for adding & subtracting hours,
minutes, & seconds (but no days, though).

On 13/09/05, hjwoudenberg@... <hjwoudenberg@...> wrote:
>
> When I round trip a date and time to fraction of days, the round trip is
> only approximate the same.
>
> Most of my times convert to repeating decimal fractions of days. Therefore
> when they are convert back to hours, minutes, seconds the time is only
> approximately the same, especially if the time has fractions of seconds.
>
> Does anyone have a trick to avoid this problem?
>
> hjw
>
> ________________________________
>
>
> Visit your group "ISO8601" on the web.
>
> To unsubscribe from this group, send an email to:
> ISO8601-unsubscribe@yahoogroups.com
>
>
> ________________________________
>
• ... Rounding errors always occur. ... Thus is life. ... To get secondaccuracy, you need at least six significant figures in the decimal portion when converting
Message 4 of 8 , Sep 14 7:01 AM
2005-09-13T06:40:39Z, <Hjwoudenberg@...>:

> When I round trip a date and time to fraction of days, the round
> trip is only approximate the same.

Rounding errors always occur.

> Most of my times convert to repeating decimal fractions of days.
> Therefore when they are convert back to hours, minutes, seconds the
> time is only approximately the same, especially if the time has
> fractions of seconds.

Thus is life.

> Does anyone have a trick to avoid this problem?

To get secondaccuracy, you need at least six significant figures in
the decimal portion when converting to days (day.123,456). It will
never be a perfect round trip. If you want millisecondaccuracy, you
will need at least 9 significant figures past the decimal
(day.123,456,789).

> hjw

Ŭalabio‽
• ... trip is ... Broadly, two ways of handling: Others have touched on the idea of using seconds, (which Unix does) and there are variants: 1) Just use seconds
Message 5 of 8 , Sep 14 11:36 AM
--- In ISO8601@yahoogroups.com, hjwoudenberg@a... wrote:
> When I round trip a date and time to fraction of days, the round
trip is
> only approximate the same.
>
> hjw

Others have touched on the idea of using seconds, (which Unix does)
and there are variants:
1) Just use seconds as the fundamental interval. When days are
needed, recover days as INT(SECS/86400) and seconds_within_day = MOD
(SECS, 86400)
2) Use two words, one for days, one for seconds within days (may help
get over precision issues)
This would extend to any "tic" which is a submukltiple of a second,
like milliseconds. (You don't say how fine a time interval you must
resolve.

knowing an acceptable resolution and carrying enough precision.

If 1 second resolution suffices, there are 86400 s/day, and you have
to carry AT LEAST 5 decimals in your day fraction. I would strongly
recommend a guard digit, so use six digits. If you want milliseconds,
nine digits in the fraction. Then when you go back to seconds, force
round it to the resolution you have chosen.
• there is a third way: How about we slow the earth down just a smidgeon so seconds are evenly divisible by multiples of 2 to the n, for some reasonably large n?
Message 6 of 8 , Sep 14 8:17 PM
there is a third way:

How about we slow the earth down just a smidgeon so seconds are evenly
divisible by multiples of 2 to the n, for some reasonably large n?

tex

johnmsteele wrote:
>
> --- In ISO8601@yahoogroups.com, hjwoudenberg@a... wrote:
> > When I round trip a date and time to fraction of days, the round
> trip is
> > only approximate the same.
> >
> > hjw
>
> Broadly, two ways of handling:
>
> Others have touched on the idea of using seconds, (which Unix does)
> and there are variants:
> 1) Just use seconds as the fundamental interval. When days are
> needed, recover days as INT(SECS/86400) and seconds_within_day = MOD
> (SECS, 86400)
> 2) Use two words, one for days, one for seconds within days (may help
> get over precision issues)
> This would extend to any "tic" which is a submukltiple of a second,
> like milliseconds. (You don't say how fine a time interval you must
> resolve.
>
> The second option is to always round your answer. That requires
> knowing an acceptable resolution and carrying enough precision.
>
> If 1 second resolution suffices, there are 86400 s/day, and you have
> to carry AT LEAST 5 decimals in your day fraction. I would strongly
> recommend a guard digit, so use six digits. If you want milliseconds,
> nine digits in the fraction. Then when you go back to seconds, force
> round it to the resolution you have chosen.
>
>
>
>
>
>
>

--
-------------------------------------------------------------
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
-------------------------------------------------------------
• LOL
Message 7 of 8 , Sep 14 10:00 PM
LOL

On 14/09/05, Tex Texin <tex@...> wrote:
> there is a third way:
>
> How about we slow the earth down just a smidgeon so seconds are evenly
> divisible by multiples of 2 to the n, for some reasonably large n?
>
> tex
• You are aware, I hope, that the ISO-8601 2005 you refer to in the subject line, was just an April Fool s joke? That the current version is ISO 8601:2004, and
Message 8 of 8 , Sep 28 5:50 PM
You are aware, I hope, that the ISO-8601 2005 you refer to in the
subject line, was just an April Fool's joke? That the current version
is ISO 8601:2004, and that fractional days are not really part of ISO
8601?

See msg #1287, Subject: New version ISO 8601:2005 released 2005-04-01

John

--- In ISO8601@yahoogroups.com, hjwoudenberg@a... wrote:
> When I round trip a date and time to fraction of days, the round
trip is
> only approximate the same.
>
> Most of my times convert to repeating decimal fractions of days.
Therefore
> when they are convert back to hours, minutes, seconds the time is only
> approximately the same, especially if the time has fractions of seconds.
>
> Does anyone have a trick to avoid this problem?
>
> hjw
Your message has been successfully submitted and would be delivered to recipients shortly.