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 2 of 2 — ← Prev page 1 [2]

#25438

On 10/02/2013 05:12 PM, Andreas Leitgeb wrote:
> 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).
>

What you are describing is not a duration or interval in the general 
sense but a stylized way of expressing the time between two specific 
points in time, not unlike a the numerous ways there are for expressing 
a specific point in time.

General durations are mathematical numerical value types that support 
normal binary numerical operations like addition/subtraction (duration 
versus duration) and multiplication/division (duration versus numerical) 
and comparisons (d vs. d).

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

#25440

Silvio <silvio@internet.com> wrote:
> On 10/02/2013 05:12 PM, Andreas Leitgeb wrote:
>> 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 you are describing is not a duration or interval in the general 
> sense but a stylized way of expressing the time between two specific 
> points in time, not unlike a the numerous ways there are for expressing 
> a specific point in time.

Yes, kind of.  I never claimed to expect algebraic field properties.

If I had my way, I'd slow down earth-spin and accellerate it's movement
around the sun, until we reach an exact 100 days year. ;-)
My days are all too short, anyway... (that's why I'm writing this at 2am)

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

#25441

On 10/2/2013 11:12 AM, Andreas Leitgeb wrote:
> 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").

Maybe two classes RelativeTime and AbsoluteTime so your
problem could be one RelativeTime with 1 HOUR and one
AbsoluteTime with HOUR X (where X is now hour  minus one).

Arne

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

#25460

On 10/2/2013 9:36 PM, Arne Vajhøj wrote:
> On 10/2/2013 11:12 AM, Andreas Leitgeb wrote:
>> 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").
>
> Maybe two classes RelativeTime and AbsoluteTime so your
> problem could be one RelativeTime with 1 HOUR and one
> AbsoluteTime with HOUR X (where X is now hour  minus one).

Illustration:

import java.util.ArrayList;
import java.util.Calendar;
import java.util.List;

public class TimeManipulation {
	public static interface TimeUpdate {
		public void applyTo(Calendar cal);
	}
	public static class AbsoluteTimeUpdate implements TimeUpdate {
		private int value;
		private int field;
		public AbsoluteTimeUpdate(int value, int field) {
			this.value = value;
			this.field = field;
		}
		@Override
		public void applyTo(Calendar cal) {
			cal.set(field, value);
		}
	}
	public static class RelativeTimeUpdate implements TimeUpdate {
		private int value;
		private int field;
		public RelativeTimeUpdate(int value, int field) {
			super();
			this.value = value;
			this.field = field;
		}
		@Override
		public void applyTo(Calendar cal) {
			cal.add(field, value);
		}
	}
	private List<TimeUpdate> upds;
	public TimeManipulation(TimeUpdate... upds) {
		this.upds = new ArrayList<TimeUpdate>();
		for(TimeUpdate upd : upds) this.upds.add(upd);
	}
	public void applyTo(Calendar cal) {
		for(TimeUpdate upd : upds) {
			upd.applyTo(cal);
		}
	}
	public static void main(String[] args) {
		TimeManipulation tm = new TimeManipulation(new RelativeTimeUpdate(1, 
Calendar.DAY_OF_MONTH),
			                                       new RelativeTimeUpdate(-1, 
Calendar.HOUR_OF_DAY));
		Calendar cal = Calendar.getInstance();
		System.out.println(cal.getTime());
		tm.applyTo(cal);
		System.out.println(cal.getTime());
	}
}

Arne

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

#25461

Arne Vajhøj <arne@vajhoej.dk> wrote:
>> Maybe two classes RelativeTime and AbsoluteTime so your
>> problem could be one RelativeTime with 1 HOUR and one
>> AbsoluteTime with HOUR X (where X is now hour  minus one).
> Illustration: [...]

Thanks for the illustration, because I wasn't really able to
follow you on the Relative/Absolute distinction in that context.
(maybe I was also confused by the "RelativeTime with 1 HOUR")

Now, that I think I see what you meant, I can say, that I wouldn't
need the "AbsoluteTimeUpdate", at least not for my intervals.

When I was speaking of "tomorrow same wallclocktime" part I was NOT
thinking of "adding 24 hours, then setting the hour to old hour value."
While Calendar might internally do something like that for adding days,
*I* don't have to code that explicitly. For me as a user of Calendar
it's just add()s for each relevant field.

For any real mixture of set()ting and add()ing fields at the same
level, I agree to all the warnings about its imminent fragility.

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

#26230

On 10/4/2013 5:17 AM, Andreas Leitgeb wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> Maybe two classes RelativeTime and AbsoluteTime so your
>>> problem could be one RelativeTime with 1 HOUR and one
>>> AbsoluteTime with HOUR X (where X is now hour  minus one).
>> Illustration: [...]
>
> Thanks for the illustration, because I wasn't really able to
> follow you on the Relative/Absolute distinction in that context.
> (maybe I was also confused by the "RelativeTime with 1 HOUR")
>
> Now, that I think I see what you meant, I can say, that I wouldn't
> need the "AbsoluteTimeUpdate", at least not for my intervals.

It may not be a perfect fit for what you need.

But as a data structure changing a Calendar I think it is
both simple and powerful.

Arne

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web