Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #25416 > unrolled thread

Searching for a "TimeInterval" type...

Back to article view | Back to comp.lang.java.programmer

Contents

  Searching for a "TimeInterval" type... Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-01 17:29 +0000
    Re: Searching for a "TimeInterval" type... markspace <markspace@nospam.nospam> - 2013-10-01 11:11 -0700
      Re: Searching for a "TimeInterval" type... markspace <markspace@nospam.nospam> - 2013-10-01 11:22 -0700
        Re: Searching for a "TimeInterval" type... Arne Vajhøj <arne@vajhoej.dk> - 2013-10-01 19:51 -0400
        Re: Searching for a "TimeInterval" type... Sebastian <news@seyweiler.dyndns.org> - 2013-10-02 09:23 +0200
          Re: Searching for a "TimeInterval" type... Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-02 14:42 +0000
            Re: Searching for a "TimeInterval" type... Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-10-03 07:57 +0200
              Re: Searching for a "TimeInterval" type... Arne Vajhøj <arne@vajhoej.dk> - 2013-10-03 20:44 -0400
                Re: Searching for a "TimeInterval" type... Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-10-05 04:22 +0200
            Re: Searching for a "TimeInterval" type... Sebastian <news@seyweiler.dyndns.org> - 2013-10-16 19:43 +0200
    Re: Searching for a "TimeInterval" type... Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-10-01 21:54 +0200
      Re: Searching for a "TimeInterval" type... Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-02 15:02 +0000
    Re: Searching for a "TimeInterval" type... Silvio <silvio@internet.com> - 2013-10-01 22:04 +0200
    Re: Searching for a "TimeInterval" type... Arne Vajhøj <arne@vajhoej.dk> - 2013-10-01 19:53 -0400
      Re: Searching for a "TimeInterval" type... Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-02 15:12 +0000
        Re: Searching for a "TimeInterval" type... Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2013-10-02 23:25 +0300
          Re: Searching for a "TimeInterval" type... Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-02 23:56 +0000
            Re: Searching for a "TimeInterval" type... Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2013-10-03 17:18 +0300
              Re: Searching for a "TimeInterval" type... Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-03 18:54 +0000
                Re: Searching for a "TimeInterval" type... Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2013-10-03 23:53 +0300
        Re: Searching for a "TimeInterval" type... Silvio <silvio@internet.com> - 2013-10-02 23:03 +0200
          Re: Searching for a "TimeInterval" type... Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-03 00:04 +0000
        Re: Searching for a "TimeInterval" type... Arne Vajhøj <arne@vajhoej.dk> - 2013-10-02 21:36 -0400
          Re: Searching for a "TimeInterval" type... Arne Vajhøj <arne@vajhoej.dk> - 2013-10-03 21:41 -0400
            Re: Searching for a "TimeInterval" type... Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-04 09:17 +0000
              Re: Searching for a "TimeInterval" type... Arne Vajhøj <arne@vajhoej.dk> - 2013-10-04 20:52 -0400

Page 1 of 2  [1] 2  Next page →

#25416 — Searching for a "TimeInterval" type...

My application will maintain Calendar instances, and I need another type
to hold "intervals", such as (5 months, 4 days and 30 minutes) that I 
could conveniently "add" to a Calendar instance.

My first thought was using another Calendar, and do a loop for the
add-operation:
   Calendar cal = ...; Calendar intvl = ...;
   for (int i=0; i<Calendar.FIELD_COUNT; i++) {
      if (intvl.isSet(i)) { cal.add(i,intvl.get(i)); }
   }
which would be fine for simple cases, but wouldn't work, if I
wanted to represent "100 days", which definitely isn't equivalent
to "3 months and 10/9 days" (depending on leapyear).  If I just
don't call "complete()", then according to the docs get() would
bomb on me, for the days-value being out of bounds.

One alternative could be to just wrap a new int[Calendar.FIELD_COUNT],
and use the Calendar-constants to index into the array, but I wonder,
if I'm perhaps missing something more elegant.  It's hard for me to
believe, that there wasn't any common need for representing intervals
of time in a mixture of units, and not just seconds.

Right now I'm optimizing for elegance not for performance.

[toc] | [next] | [standalone]

#25417

On 10/1/2013 10:29 AM, Andreas Leitgeb wrote:
> It's hard for me to
> believe, that there wasn't any common need for representing intervals
> of time in a mixture of units, and not just seconds.


I think the new JOGL stuff has an interval (they call it a Duration). 
But I don't think you're missing anything.  The Calendar class is pretty 
widely derided as missing a lot of important features, afaik.

[toc] | [prev] | [next] | [standalone]

#25418

On 10/1/2013 11:11 AM, markspace wrote:
> On 10/1/2013 10:29 AM, Andreas Leitgeb wrote:
>> It's hard for me to
>> believe, that there wasn't any common need for representing intervals
>> of time in a mixture of units, and not just seconds.
>
>
> I think the new JOGL stuff has an interval (they call it a Duration).
> But I don't think you're missing anything.  The Calendar class is pretty
> widely derided as missing a lot of important features, afaik.
>
>


I really loused that up.  It's JODA time, and the class is Period.

<http://download.java.net/jdk8/docs/api/java/time/Period.html>

[toc] | [prev] | [next] | [standalone]

#25421

On 10/1/2013 2:22 PM, markspace wrote:
> On 10/1/2013 11:11 AM, markspace wrote:
>> On 10/1/2013 10:29 AM, Andreas Leitgeb wrote:
>>> It's hard for me to
>>> believe, that there wasn't any common need for representing intervals
>>> of time in a mixture of units, and not just seconds.
>>
>>
>> I think the new JOGL stuff has an interval (they call it a Duration).
>> But I don't think you're missing anything.  The Calendar class is pretty
>> widely derided as missing a lot of important features, afaik.
>
> I really loused that up.  It's JODA time, and the class is Period.
>
> <http://download.java.net/jdk8/docs/api/java/time/Period.html>

Depending on requirements Duration may be better than Period.

Duration takes units small than day - period does not. Duration
is pure interval while Period follow clock (which is different when
switching to and from DST).

Arne

[toc] | [prev] | [next] | [standalone]

#25425

Am 01.10.2013 20:22, schrieb markspace:
> On 10/1/2013 11:11 AM, markspace wrote:
>> On 10/1/2013 10:29 AM, Andreas Leitgeb wrote:
>>> It's hard for me to
>>> believe, that there wasn't any common need for representing intervals
>>> of time in a mixture of units, and not just seconds.
>>
>>
>> I think the new JOGL stuff has an interval (they call it a Duration).
>> But I don't think you're missing anything. The Calendar class is pretty
>> widely derided as missing a lot of important features, afaik.
>>
>>
>
>
> I really loused that up. It's JODA time, and the class is Period.
>
> <http://download.java.net/jdk8/docs/api/java/time/Period.html>
>
>
One nice thing about using Joda would be that your code will stand a 
good chance of being easily portable to the new Data and Time API in the 
upcoming Java 8 release, which is mostly inspired by Joda time. 
Personally, I'd not start anything new based on the current Calendar 
class and its relatives.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#25428

Thanks to mark, Arne & Sebastian for pointing towards Joda and
future Java 8. It's good to know that this swamp is getting dried,
but I'll probably not hold my breath for it, and I'll probably stay
with Calendar for now, but at least I'm now aware to not fully embrace
it, but only pick minimal functionality from it. I hope I will then be
able to eventually translate to new date-API once Java 8 arrives.

Also, I actually (unfortunately) do need to represent mixes of units
and a day definitely isn't the same as 86400 seconds. Calendar seems
to support most of what I need. Now, that I know I didn't just miss a
standard class, I'll do my own for the type of intervals I need. (and
it seems to me (after looking at mark's link) as if neither Period nor
Duration fits my bill completely, anyway.)

Sebastian <news@seyweiler.dyndns.org> wrote:
>> <http://download.java.net/jdk8/docs/api/java/time/Period.html>
> One nice thing about using Joda would be that your code will stand a 
> good chance of being easily portable to the new Data and Time API in the 
> upcoming Java 8 release, which is mostly inspired by Joda time. 
> Personally, I'd not start anything new based on the current Calendar 
> class and its relatives.
>
> -- Sebastian

[toc] | [prev] | [next] | [standalone]

#25445

On 2013-10-02 16:42, Andreas Leitgeb allegedly wrote:
> Thanks to mark, Arne & Sebastian for pointing towards Joda and
> future Java 8. It's good to know that this swamp is getting dried,
> but I'll probably not hold my breath for it, and I'll probably stay
> with Calendar for now, but at least I'm now aware to not fully embrace
> it, but only pick minimal functionality from it. I hope I will then be
> able to eventually translate to new date-API once Java 8 arrives.
> 
> Also, I actually (unfortunately) do need to represent mixes of units
> and a day definitely isn't the same as 86400 seconds. Calendar seems
> to support most of what I need. Now, that I know I didn't just miss a
> standard class, I'll do my own for the type of intervals I need. (and
> it seems to me (after looking at mark's link) as if neither Period nor
> Duration fits my bill completely, anyway.)
> 
> Sebastian <news@seyweiler.dyndns.org> wrote:
>>> <http://download.java.net/jdk8/docs/api/java/time/Period.html>
>> One nice thing about using Joda would be that your code will stand a 
>> good chance of being easily portable to the new Data and Time API in the 
>> upcoming Java 8 release, which is mostly inspired by Joda time. 
>> Personally, I'd not start anything new based on the current Calendar 
>> class and its relatives.
>>
>> -- Sebastian

Having worked with with JODA in the past, I *strongly* recommend you
made use of it, regardless of the circumstances.

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#25459

On 10/3/2013 1:57 AM, Daniele Futtorovic wrote:
> On 2013-10-02 16:42, Andreas Leitgeb allegedly wrote:
>> Sebastian <news@seyweiler.dyndns.org> wrote:
>>>> <http://download.java.net/jdk8/docs/api/java/time/Period.html>
>>> One nice thing about using Joda would be that your code will stand a
>>> good chance of being easily portable to the new Data and Time API in the
>>> upcoming Java 8 release, which is mostly inspired by Joda time.
>>> Personally, I'd not start anything new based on the current Calendar
>>> class and its relatives.
>
> Having worked with with JODA in the past, I *strongly* recommend you
> made use of it, regardless of the circumstances.

Joda has a very good reputation.

I have used Joda at a few occasions and I must admit that I find
it over-engineered.

Arne

[toc] | [prev] | [next] | [standalone]

#26232

On 2013-10-04 02:44, Arne Vajhøj allegedly wrote:
> On 10/3/2013 1:57 AM, Daniele Futtorovic wrote:
>> On 2013-10-02 16:42, Andreas Leitgeb allegedly wrote:
>>> Sebastian <news@seyweiler.dyndns.org> wrote:
>>>>> <http://download.java.net/jdk8/docs/api/java/time/Period.html>
>>>> One nice thing about using Joda would be that your code will stand a
>>>> good chance of being easily portable to the new Data and Time API in
>>>> the
>>>> upcoming Java 8 release, which is mostly inspired by Joda time.
>>>> Personally, I'd not start anything new based on the current Calendar
>>>> class and its relatives.
>>
>> Having worked with with JODA in the past, I *strongly* recommend you
>> made use of it, regardless of the circumstances.
> 
> Joda has a very good reputation.
> 
> I have used Joda at a few occasions and I must admit that I find
> it over-engineered.

I don't know about that. All that date and time stuff is nigh-insanely
complicated. Relative to that, Joda-Time is rather simple, and it does
the job. I have also found it pleasurable to use, in terms of coding.
YMMV with regards to the latter, but chances are it won't w.r.t. the
former; hence my unadorned recommendation.

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#26341

Am 02.10.2013 16:42, schrieb Andreas Leitgeb:
> Thanks to mark, Arne&  Sebastian for pointing towards Joda and
> future Java 8. It's good to know that this swamp is getting dried,
> but I'll probably not hold my breath for it, and I'll probably stay
> with Calendar for now, but at least I'm now aware to not fully embrace
> it, but only pick minimal functionality from it. I hope I will then be
> able to eventually translate to new date-API once Java 8 arrives.
>
[snip]

It just came to my attention that there is a JDK 1.7 backport of the new 
Date and Time API. On the JavaOne 2013 pages there are downloadable 
presentations that explain the API. The backport itself is at: 
http://threeten.github.io/

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#25419

On 01.10.13 19.29, Andreas Leitgeb wrote:
> My application will maintain Calendar instances, and I need another type
> to hold "intervals", such as (5 months, 4 days and 30 minutes) that I
> could conveniently "add" to a Calendar instance.

There is no such class in Java. The natural representation of time span 
is an integer, in doubt a long, holding he difference of Calendar.getTime().

However, there are some non-unique definitions of time spans in 
business. E.g. one month. It may mean anything between 28 and 31 days as 
well as an undefined time period, e.g. if you add one month to Jan. 30th.

> My first thought was using another Calendar, and do a loop for the
> add-operation:
>     Calendar cal = ...; Calendar intvl = ...;
>     for (int i=0; i<Calendar.FIELD_COUNT; i++) {
>        if (intvl.isSet(i)) { cal.add(i,intvl.get(i)); }
>     }
> which would be fine for simple cases, but wouldn't work, if I
> wanted to represent "100 days", which definitely isn't equivalent
> to "3 months and 10/9 days" (depending on leapyear).  If I just
> don't call "complete()", then according to the docs get() would
> bomb on me, for the days-value being out of bounds.

That's the problem. You first need a /complete/ definition what should 
happen, removing all undefined constellations.

> One alternative could be to just wrap a new int[Calendar.FIELD_COUNT],
> and use the Calendar-constants to index into the array, but I wonder,
> if I'm perhaps missing something more elegant.

You missed nothing. You do not even need so much fields. In general 
three fields should be sufficient with respect to the Gregorian 
Calendar. Years, months and everything else. Have a look at the oracle 
PL/SQL interval types.

However, for business this might sill be insufficient. There are terms 
like 'after three business days'. The result might be different from 
country to country.

> It's hard for me to
> believe, that there wasn't any common need for representing intervals
> of time in a mixture of units, and not just seconds.

There are many needs for time intervals. There is just no unique 
definition of the requirement.


Marcel

[toc] | [prev] | [next] | [standalone]

#25429

Marcel Müller <news.5.maazl@spamgourmet.org> wrote:
> However, there are some non-unique definitions of time spans in 
> business. E.g. one month. It may mean anything between 28 and 31 days as 
> well as an undefined time period, e.g. if you add one month to Jan. 30th.

Calendar fortunately deals quite well with my needs, already.
My intervals do not translate into numbers of seconds.

>> One alternative could be to just wrap a new int[Calendar.FIELD_COUNT],
>> and use the Calendar-constants to index into the array, but I wonder,
>> if I'm perhaps missing something more elegant.
> You missed nothing. [...]

I noticed that GregorianCalendar is not final, so I'm now extending my 
Interval type from that, overriding those methods that would "prematurely"
do calls to "complete()", or check valid ranges.  Among others I'm overriding
getMinimum and getMaximum to return Integer.MIN_VALUE and .MAX_VALUE .

I'll see if that is enough to allow "100 days" be represented without 
unintended propagation to months.

> However, for business this might sill be insufficient. There are terms 
> like 'after three business days'. The result might be different from 
> country to country.

Business day logic is not part of my task. (It might be later implemented
on top of Calendar and my interval-class, though)

Thanks for pointing out the pitfalls with date&interval-arithmetics.

[toc] | [prev] | [next] | [standalone]

#25420

On 10/01/2013 07:29 PM, Andreas Leitgeb wrote:
> My application will maintain Calendar instances, and I need another type
> to hold "intervals", such as (5 months, 4 days and 30 minutes) that I
> could conveniently "add" to a Calendar instance.
>
> My first thought was using another Calendar, and do a loop for the
> add-operation:
>     Calendar cal = ...; Calendar intvl = ...;
>     for (int i=0; i<Calendar.FIELD_COUNT; i++) {
>        if (intvl.isSet(i)) { cal.add(i,intvl.get(i)); }
>     }
> which would be fine for simple cases, but wouldn't work, if I
> wanted to represent "100 days", which definitely isn't equivalent
> to "3 months and 10/9 days" (depending on leapyear).  If I just
> don't call "complete()", then according to the docs get() would
> bomb on me, for the days-value being out of bounds.
>
> One alternative could be to just wrap a new int[Calendar.FIELD_COUNT],
> and use the Calendar-constants to index into the array, but I wonder,
> if I'm perhaps missing something more elegant.  It's hard for me to
> believe, that there wasn't any common need for representing intervals
> of time in a mixture of units, and not just seconds.
>
> Right now I'm optimizing for elegance not for performance.
>

There is little point in a duration type using a value that represents 
mixed number of units. Year and month are not universal time units and 
can not be used to hold general durations.

The difference between two specific points in time can be expressed in a 
mixed number of units, a general duration can not.

Use something like seconds or milliseconds. Calendar has a convenient 
way of adding or subtracting such durations. If you need to express a 
relative duration between two specific points in time you can create 
some fancy function using Calendar and its fields or use an existing one.

[toc] | [prev] | [next] | [standalone]

#25422

On 10/1/2013 1:29 PM, Andreas Leitgeb wrote:
> My application will maintain Calendar instances, and I need another type
> to hold "intervals", such as (5 months, 4 days and 30 minutes) that I
> could conveniently "add" to a Calendar instance.
>
> My first thought was using another Calendar, and do a loop for the
> add-operation:
>     Calendar cal = ...; Calendar intvl = ...;
>     for (int i=0; i<Calendar.FIELD_COUNT; i++) {
>        if (intvl.isSet(i)) { cal.add(i,intvl.get(i)); }
>     }
> which would be fine for simple cases, but wouldn't work, if I
> wanted to represent "100 days", which definitely isn't equivalent
> to "3 months and 10/9 days" (depending on leapyear).  If I just
> don't call "complete()", then according to the docs get() would
> bomb on me, for the days-value being out of bounds.
>
> One alternative could be to just wrap a new int[Calendar.FIELD_COUNT],
> and use the Calendar-constants to index into the array, but I wonder,
> if I'm perhaps missing something more elegant.  It's hard for me to
> believe, that there wasn't any common need for representing intervals
> of time in a mixture of units, and not just seconds.
>
> Right now I'm optimizing for elegance not for performance.

I would be tempted to go for the simple solution with a class
that contains two ints: number of units and a Calendar
unit identifier.

Arne

[toc] | [prev] | [next] | [standalone]

#25430

Arne Vajhøj <arne@vajhoej.dk> wrote:
> I would be tempted to go for the simple solution with a class
> that contains two ints: number of units and a Calendar
> unit identifier.

Unfortunately, that would be too simple for my needs.

Some example interval of what I'm going to deal with can be
described as "tomorrow one (wall-clock)hour earlier". This just
isn't the same as in "23 hours" (nor as "82800 seconds").

Thanks anyway for answering (also to Silvio, who also suggested
simply going for seconds-based durations).

[toc] | [prev] | [next] | [standalone]

#25437

Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> writes:

> Some example interval of what I'm going to deal with can be
> described as "tomorrow one (wall-clock)hour earlier". This just
> isn't the same as in "23 hours" (nor as "82800 seconds").

What will that be when called between midnight and 01:00?

-- 
Jukka Lahtinen

[toc] | [prev] | [next] | [standalone]

#25439

Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> wrote:
> Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> writes:
>> Some example interval of what I'm going to deal with can be
>> described as "tomorrow one (wall-clock)hour earlier". This just
>> isn't the same as in "23 hours" (nor as "82800 seconds").
> What will that be when called between midnight and 01:00?

It would be the same day between 23:00 and midnight, even if the
day itself is a DST-switch-day.

The other question: what that would be "one day minus one hour" after
a timestamp between 3am and 4am of the saturday before Spring DST day?
Answer: I don't care. That would be a weekend, and I happen not to care
about weekends for my task ;-)
It's just not specified. If a solution works for all other cases, it'll
be fine for the spec, even if it gave me a date in year 42 BCE for that
particular situation. (ditto for Autumn, although I'd personally tend to
prefer the second one of the two "2am-3am" hours then)

[toc] | [prev] | [next] | [standalone]

#25452

Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> writes:
> Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> wrote:
>> Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> writes:
>>> Some example interval of what I'm going to deal with can be
>>> described as "tomorrow one (wall-clock)hour earlier". This just
>>> isn't the same as in "23 hours" (nor as "82800 seconds").
>> What will that be when called between midnight and 01:00?

> It would be the same day between 23:00 and midnight, even if the
> day itself is a DST-switch-day.

In that case it isn't tomorrow, so "tomorrow one (wall-clock)hour
earlier" is a bit misleading 1 hour in every 24. That is over 4% of
time.

> The other question: what that would be "one day minus one hour" after
> a timestamp between 3am and 4am of the saturday before Spring DST day?
> Answer: I don't care. That would be a weekend, and I happen not to care
> about weekends for my task ;-)

Logically it would probably skip one hour in Spring and use one hour
twice in Fall, when called near the time of the change. And the other
way round when the result would be near the time of the change. 
(Or is it the other way round..)
And apparently this doesn't matter. 

-- 
Jukka Lahtinen

[toc] | [prev] | [next] | [standalone]

#25457

Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> wrote:
> Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> writes:
>> Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> wrote:
>>> Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> writes:
>>>> Some example interval of what I'm going to deal with can be
>>>> described as "tomorrow one (wall-clock)hour earlier". This just
>>>> isn't the same as in "23 hours" (nor as "82800 seconds").
>>> What will that be when called between midnight and 01:00?
>> It would be the same day between 23:00 and midnight, even if the
>> day itself is a DST-switch-day.
> In that case it isn't tomorrow, so "tomorrow one (wall-clock)hour
> earlier" is a bit misleading 1 hour in every 24. That is over 4% of
> time.

The only thing that may have been misleading was my short verbal
representation.  A (slightly) more precise one could have been:
  "next day same wallclock time, but then one hour earlier"

(making the "next day same wallclock time" merely a landmark on the
route to the target time. Fortunately, we're smart enough to arrive
there without waiting for next day same time and then needing to go
one hour backwards in time)

A really exact description of that concept of mixed units timespans
is implemented by my GregorianCalendar-derived Interval class, although
I didn't test it yet. So little time, so much to do ;-)

[toc] | [prev] | [next] | [standalone]

#25458

Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> writes:
> Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> wrote:
>> Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> writes:
>>> Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> wrote:
>>>> Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> writes:
>>>>> Some example interval of what I'm going to deal with can be
>>>>> described as "tomorrow one (wall-clock)hour earlier". This just
>>>>> isn't the same as in "23 hours" (nor as "82800 seconds").
>>>> What will that be when called between midnight and 01:00?
>>> It would be the same day between 23:00 and midnight, even if the
>>> day itself is a DST-switch-day.
>> In that case it isn't tomorrow, so "tomorrow one (wall-clock)hour
>> earlier" is a bit misleading 1 hour in every 24. That is over 4% of
>> time.

> The only thing that may have been misleading was my short verbal
> representation.  A (slightly) more precise one could have been:
>   "next day same wallclock time, but then one hour earlier"

Or just changing the order of words to "one hour before the same time
tomorrow". 
Well, working with computers you learn to nitpick and tend to check what
is really meant with ambiguous expressions..

-- 
Jukka Lahtinen

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web