TimeSpan Convenience

C

Chris Smith

Store time spans as long. Format them using Calendar. Incidentally,
there is no way the code at your link can be correct. In general, it is
impossible to phrase a time interval in days (or any larger unit)
without knowing the starting time, as well as the interval. For
example, in localities that use daylight savings time, an interval of 23
hours is less than a day most of the time, but it's exactly a day when
it begins immediately prior to the beginning of daylight savings time.
Any interval that spans either DST boundary will be similarly affected.
There are other concerns as well, but that's the obvious one.

Mark Thornton said:
javax.xml.datatype.Duration

That appears to be a correct implementation.
 
M

Mark Thornton

Chris said:
Store time spans as long. Format them using Calendar. Incidentally,
there is no way the code at your link can be correct. In general, it is
impossible to phrase a time interval in days (or any larger unit)
without knowing the starting time, as well as the interval.

Just because the duration is variable doesn't mean the period is
meaningless. For example, I like most in the UK, get paid monthly. So as
the length of calendar months varies, so too does the duration between
pay packets. Joda time describes this concept as a "period" as opposed
to a duration (which always is an exact number of milliseconds in legth)
or an interval which is the time between two specific instants.

I haven't looked closely enough at the .NET class to determine which
concept(s) it corresponds to.

Mark Thornton
 
C

Chris Smith

Mark Thornton said:
Just because the duration is variable doesn't mean the period is
meaningless.

Absolutely. I was commenting on the code at the link posted. It is an
object that is initialized with a long (time interval in milliseconds),
and contains methods to get days, hours, and minutes from there. I
merely pointed out that it must be wrong sometimes.
 
J

Josef Pfleger

Mark said:
> I haven't looked closely enough at the .NET class to determine which
> concept(s) it corresponds to.

It corresponds to the period concept, thus storing a TimeSpan *only* as
a number of ticks (1 tick equals 100 nanoseconds), nothing else,
especially no starting point referring to a calendar.


Chris said:
> I was commenting on the code at the link posted. It is an
> object that is initialized with a long (time interval inmilliseconds),
> and contains methods to get days, hours, and minutes from there. I
> merely pointed out that it must be wrong sometimes.

Since we have established to differ periods and timespans from durations
or intervals, I have to say that my code at the link posted implements
the period concept and is therefore correct and equal to .NET's TimeSpan
structure. The only difference: It stores milliseconds rather than ticks.
There are a lot of situations where this makes sense. For example, my
long-haul flight will always last 26 hours and 21 minutes, no matter how
many timezones I cross or in what century the destination country
decided to introduce DST.

Josef
 
C

Chris Smith

Josef Pfleger said:
Since we have established to differ periods and timespans from durations
or intervals, I have to say that my code at the link posted implements
the period concept and is therefore correct and equal to .NET's TimeSpan
structure.
For example, my long-haul flight will always last 26 hours and 21 minutes,
no matter how many timezones I cross or in what century the destination
country decided to introduce DST.

The code at the link you posted said:

TimeSpan rem = new TimeSpan(
System.currentTimeMillis() - xmas.getTimeInMillis());

System.out.printf("%d days, %d hours and %d minutes till xMas ;-)",
rem.getDays(), rem.getHours(), rem.getMinutes());

It's the days that cause the problem. You can easily get seconds,
minutes, and hours from calculations on the number of milliseconds, but
days depends on the starting time and DST conventions. So no, that code
is not correct.
 
J

John Ersatznom

Chris said:
The code at the link you posted said:

TimeSpan rem = new TimeSpan(
System.currentTimeMillis() - xmas.getTimeInMillis());

System.out.printf("%d days, %d hours and %d minutes till xMas ;-)",
rem.getDays(), rem.getHours(), rem.getMinutes());

It's the days that cause the problem. You can easily get seconds,
minutes, and hours from calculations on the number of milliseconds, but
days depends on the starting time and DST conventions. So no, that code
is not correct.

If I were implementing this stuff:
a) I'd use a number of milliseconds as the internal representation of a
time interval or duration.
b) Date objects would internally wrap milliseconds since the epoch, in a
long, and be UTC. To get a localized date it would be interpreted
relative to a Locale to get its date and time in a particular time zone.
Localization of dates would be a peripheral thing; the core data would
all be in UTC, and you could compare and find that the current date in
london and the same date in new york were equal even though they printed
differently, etc. There'd be separate Date (UTC) and LocalizedDate classes.
c) Failing b), I'd have all calculations internally change incoming
dates to UTC and results to the desired locale. Date parameters would be
accompanyable by optional Locale objects and without them interpreted
relative to the system locale.
 
C

Chris Smith

John Ersatznom said:
If I were implementing this stuff:
a) I'd use a number of milliseconds as the internal representation of a
time interval or duration.
b) Date objects would internally wrap milliseconds since the epoch, in a
long, and be UTC. To get a localized date it would be interpreted
relative to a Locale to get its date and time in a particular time zone.
Localization of dates would be a peripheral thing; the core data would
all be in UTC, and you could compare and find that the current date in
london and the same date in new york were equal even though they printed
differently, etc. There'd be separate Date (UTC) and LocalizedDate classes.
c) Failing b), I'd have all calculations internally change incoming
dates to UTC and results to the desired locale. Date parameters would be
accompanyable by optional Locale objects and without them interpreted
relative to the system locale.

Good news! That's exactly how it works. Instead of LocalizedDate, we
have Calendar (and TimeZone; each calendar has a time zone implicitly
associated with it). All of the methods of java.util.Date that depend
on localization were deprecated in the Java 1.1 release cycle. in 1998.
Date does track dates in absolute time in UTC, and Calendar can be used
to convert that to dates and times in any given locale. It all works
fine.

This thread appears to have originated because someone wanted an easier
interface for it, and the interface was simplified too much by
eliminating any knowledge of the beginning of a time interval or locale-
specific information, which is important if you want to express the
interval in days or any unit dependent on days.
 
J

John Ersatznom

Chris said:
This thread appears to have originated because someone wanted an easier
interface for it, and the interface was simplified too much by
eliminating any knowledge of the beginning of a time interval or locale-
specific information, which is important if you want to express the
interval in days or any unit dependent on days.

For a generic duration object, you'd use the approximation of 1 day ~=
86400 seconds when expressing it in the UI, and internally it would just
be a number of msec.

All of what I wrote in this thread being intended for any similar
situation arising in any language (and any alternative implementations
in Java *cough*java.sql.Date*cough* ...)
 
C

Chris Smith

John Ersatznom said:
For a generic duration object, you'd use the approximation of 1 day ~=
86400 seconds when expressing it in the UI, and internally it would just
be a number of msec.

I would? I suppose I would do that with days or years only if that
level of precision really didn't matter, and I'd document it since I'm
really giving the wrong answer.
 
J

Josef Pfleger

Chris said:
> It's the days that cause the problem. You can easily get seconds,
> minutes, and hours from calculations on the number of milliseconds,
> but days depends on the starting time and DST conventions.

So it seems that the definition of the word 'day' has become the point
of interest here. According to the first definition in the Oxford
English Dictionary, a day is "a period of twenty-four hours as a unit of
time, reckoned from midnight to midnight and corresponding to a rotation
of the earth on its axis".
http://www.askoxford.com/concise_oed/day?view=uk

Obviously, Microsoft implemented a day as a fixed unit of time according
to this definition in it's System.TimeSpan structure. So did I at the
link posted and this is why I'm still convinced that my code is correct ;-)

I realize that there are other definitions out there (some may include
DST and timezone issues) but I aimed for a simpler interface and was
basically imitating Microsoft's implementation.

- Josef
 
L

Lew

Josef said:
So it seems that the definition of the word 'day' has become the point
of interest here. According to the first definition in the Oxford
English Dictionary, a day is "a period of twenty-four hours as a unit of
time, reckoned from midnight to midnight and corresponding to a rotation
of the earth on its axis".
http://www.askoxford.com/concise_oed/day?view=uk

This definition is self-inconsistent for days when there is a timezone change,
because the period from midnight to midnight will not be twenty-four hours.
Which part of this particular definition should we invalidate?

http://www.unc.edu/~rowlett/units/dictD.html
gives three separate definitions.

- Lew
 
J

Josef Pfleger

Lew said:
This definition is self-inconsistent for days when there is a timezone
change, because the period from midnight to midnight will not be
twenty-four hours.
I agree that timezone or DST borders are not explicitly mentioned. But
it does refer to the rotation of the earth on its axis which gives a
hint that they are defining the 'mean solar day', which is 24 hours long.
Ok, so what I implemented is the 'mean solar day'. Thank you for the
clarification. I will document it accordingly.
 
M

Mark Thornton

Josef said:
So it seems that the definition of the word 'day' has become the point
of interest here. According to the first definition in the Oxford
English Dictionary, a day is "a period of twenty-four hours as a unit of
time, reckoned from midnight to midnight and corresponding to a rotation
of the earth on its axis".
http://www.askoxford.com/concise_oed/day?view=uk

And what of the midnight to midnight bit? How many days in a 24 hour
period starting at midday?

Mark Thornton
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top