www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - I made std.time for Phobos, please review my code.

reply SHOO <zan77137 nifty.com> writes:
I make std.time module for Phobos. This module provides Time, Span,
Clock, StopWatch and some utility functions for time operation.
I hope combine this module to Phobos instead of std.date.

download is here:
	http://j.mp/95aS1K (== http://dusers.dip.jp/ ... /time.d)
	http://j.mp/9p5DDu (patch for Phobos's trunk r1481)
	http://ideone.com/eiQ19 (for code view)

Besides, is there the necessary function? (This module lacks the
daylight saving time handling, because of a lack of my understanding.)


I talk about the process that reached making...

Tango is great library for D1. I am Tango user and I am indebted to
Tango well. But Tango has some probrems.

- Tango's license is BSD lisence or AFL. This license is incompatible to
Phobos's Boost license.
- The specification is disregarded, for example Object.dispose and string.
- Tango supports only D1
- In particular, deep regret is to have split resources of D into two
halves.

If possible, I want to migrate to D2. And I want to be separated from
Tango. However, some functions are insufficient for Phobos compared with
Tango.
The std.date module is one of the list of dissatisfaction to Phobos.
I summarize my (and some of Japanese users's) opinion following:

- I want to handle it as another thing for the time and the time span.
- I want a more structural class for time operating.
- std.date is a bit buggy...

By these reasons, I made std.time module as the first step of the
contribution for Phobos.
Apr 27 2010
next sibling parent reply Bernard Helyer <b.helyer gmail.com> writes:
On 27/04/10 20:55, SHOO wrote:

 std.date is a bit buggy...


Yeah, like a loaded gun is a bit dangerous.  :D

I will download and try, after all the issues I had with std.date.
Although, I think that handling DST is pretty vital (but very confusing).
Apr 27 2010
parent reply SHOO <zan77137 nifty.com> writes:
Bernard Helyer $B$5$s$O=q$-$^$7$?(B:

 On 27/04/10 20:55, SHOO wrote:

 std.date is a bit buggy...


 
 Yeah, like a loaded gun is a bit dangerous.  :D
 
 I will download and try, after all the issues I had with std.date.
 Although, I think that handling DST is pretty vital (but very confusing).


Thanks to your response.

I think that handling DST is necessary too.
But I am unfamiliar about DST so that people of the Ascii character
string zone are unfamiliar about multi-byte character string.
(I live in Japan which does not use DST.)
I may not exactly recognize bugs even if I implemented it.
I want to leave the implementation to other people who knows DST well.
Apr 27 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-04-27 07:22:12 -0400, SHOO <zan77137 nifty.com> said:


 Thanks to your response.
 
 I think that handling DST is necessary too.
 But I am unfamiliar about DST so that people of the Ascii character
 string zone are unfamiliar about multi-byte character string.
 (I live in Japan which does not use DST.)
 I may not exactly recognize bugs even if I implemented it.
 I want to leave the implementation to other people who knows DST well.


The problem with DST (and time zones in general) is that it's subject 
to change. DST dates were changed a couple of years ago here in Canada 
and in the United States; operating system vendors made a patch for 
this and things went smoothy (for the most part) for applications using 
the OS to know about DST. This can get more complicated though: for 
Israel (post 2005) you'll need to follow the hebrew calendar[1], and 
before 2005 it's mostly arbitrary.

I think timezones and DST management are better left to the OS. What is 
most important to have is a way to convert local dates and times to UTC 
and the reverse, and to determine the local UTC offset for a given 
time. I'd leave the rest to other libraries, or OS-specific APIs.

[1]: http://en.wikipedia.org/wiki/Israel_Summer_Time

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Apr 27 2010
prev sibling next sibling parent Bernard Helyer <b.helyer gmail.com> writes:
module test;

import std.stdio;
static import std.date;

import time;


void main()
{
    auto ttime = localtime();
    auto dtime = std.date.getUTCtime();
    dtime = std.date.UTCtoLocalTime(dtime);

    writeln(ttime);
    writeln(std.date.toString(dtime));
}

[tmp]$ ./test






Looking good so far.   :]
Apr 27 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-04-27 04:55:28 -0400, SHOO <zan77137 nifty.com> said:


 By these reasons, I made std.time module as the first step of the
 contribution for Phobos.


Looks nice. I think defining structs as you did to handle date and time 
is the way to go.

I've done something similar in the past to store dates and times which 
I like a lot. What I did was just a storage format, but templates 
allowed me to store dates and time spans with any precision while 
exposing always the same public API.

I'm pasting my code below in case it can inspire you (note that this 
code predates the new operator overloading syntax), and feel free to 
use any of this under the Boost license if applicable.


import std.date : d_time, ticksPerMs;


template isDateTime(T) {
	enum bool isDateTime = __traits(compiles, T.tick);
}

template isTimeSpan(T) {
	enum bool isTimeSpan = __traits(compiles, T.ticks);
}

enum Unit {
	// Need to be from higher precision to lower precision
	tick = 1,
	millisecond = ticksPerMs,
	second = 1000 * millisecond,
	minute = 60 * second,
	hour = 60 * minute,
	day = 24 * hour,
}

private Unit smaller(Unit a, Unit b) {
	return a < b ? a : b;
}

struct TimeSpan(T = d_time, Unit _unit = Unit.ticks) {
	// Milliseconds since 1970-01-01 00:00:00.0 UTC
	private T units = 0;
	enum Unit unit = _unit;
	
	void opAssign(T)(const T other) if (is(typeof(other.unit) == Unit) && 
smaller(unit, other.unit) == unit) {
		units = other.units * (other.unit / unit);
	}
	
	bool opEquals(ref const TimeSpan value) const {
		return units == value.units;
	}
//	bool opEquals(const TimeSpan value) const {
//		return units == value.units;
//	}
	
	TimeSpan opNeg() const {
		TimeSpan t;
		t.units = -units;
		return t;
	}
	
	void opAddAssign(T)(const T other) if (is(typeof(other.unit) == Unit) 
&& smaller(unit, other.unit) == unit) {
		units += other.units * (other.unit / unit);
	}
	auto opAdd(T)(const T other) const {
		TimeSpan!(typeof(units + other.units), smaller(unit, other.unit)) t;
		t = this;
		t += other;
		return t;
	}
	
	void opSubAssign(T)(const T other) if (is(typeof(other.unit) == Unit) 
&& smaller(unit, other.unit) == unit) {
		units -= other.units * (other.unit / unit);
	}
	auto opSub(T)(const T other) const {
		TimeSpan!(typeof(units - other.units), smaller(unit, other.unit)) t;
		t = this;
		t -= other;
		return t;
	}
	
	void opMulAssign(const T value) {
		units *= value;
	}
	TimeSpan opMul(const T value) const {
		TimeSpan t = this;
		t *= value;
		return t;
	}
	
	void opDivAssign(const T value) {
		units /= value;
	}
	TimeSpan opDiv(const T value) const {
		TimeSpan t = this;
		t /= value;
		return t;
	}
	
	 property:
	T ticks() {
		static if (unit == Unit.tick)
			return units;
		else static if (unit < Unit.tick)
			static assert(0);
		else static if (unit > Unit.tick)
			return cast(T)(milliseconds * ticksPerMs);
	}
	static if (unit == Unit.tick) {
		void ticks(T value) {
			static if (unit == Unit.tick)
				units = value;
			else static if (unit < Unit.tick)
				static assert(0);
			else static if (unit > Unit.tick)
				milliseconds = value / ticksPerMs;
		}
	}
	
	T milliseconds() {
		static if (unit == Unit.millisecond)
			return units;
		else static if (unit < Unit.millisecond)
			return cast(T)(ticks / ticksPerMs);
		else static if (unit > Unit.millisecond)
			return cast(T)(seconds * 1000);
	}
	static if (unit <= Unit.millisecond) {
		void milliseconds(T value) {
			static if (unit == Unit.millisecond)
				units = value;
			else static if (unit < Unit.millisecond)
				ticks = value * ticksPerMs;
			else static if (unit > Unit.millisecond)
				seconds = value / 1000;
		}
	}
	
	T seconds() {
		static if (unit == Unit.second)
			return units;
		else static if (unit < Unit.second)
			return cast(T)(milliseconds / 1000);
		else static if (unit > Unit.second)
			return cast(T)(minutes * 60);
	}
	static if (unit <= Unit.second) {
		void seconds(T value) {
			static if (unit == Unit.second)
				units = value;
			else static if (unit < Unit.second)
				milliseconds = value * 1000;
			else static if (unit > Unit.second)
				minutes = value / 60;
		}
	}
	
	T minutes() {
		static if (unit == Unit.minute)
			return units;
		else static if (unit < Unit.minute)
			return cast(T)(seconds / 60);
		else static if (unit > Unit.minute)
			return cast(T)(hours * 60);
	}
	static if (unit <= Unit.minute) {
		void minutes(T value) {
			static if (unit == Unit.minute)
				units = value;
			else static if (unit < Unit.minute)
				seconds = value * 60;
			else static if (unit > Unit.minute)
				hours = value / 60;
		}
	}
	
	T hours() {
		static if (unit == Unit.hour)
			return units;
		else static if (unit < Unit.hour)
			return cast(T)(minutes / 60);
		else static if (unit > Unit.hour)
			return cast(T)(days * 24);
	}
	static if (unit <= Unit.hour) {
		void hours(T value) {
			static if (unit == Unit.hour)
				units = value;
			else static if (unit < Unit.hour)
				minutes = cast(T)(value * 60);
			else static if (unit > Unit.hour)
				days = cast(T)(value / 24);
		}
	}
	
	T days() {
		static if (unit == Unit.day)
			return units;
		else static if (unit < Unit.day)
			return cast(T)(hours / 24);
		else static if (unit > Unit.day)
			static assert(0);
	}
	static if (unit <= Unit.day) {
		void days(T value) {
			static if (unit == Unit.day)
				units = value;
			else static if (unit < Unit.day)
				hours = cast(T)(value * 24);
			else static if (unit > Unit.day)
				static assert(0);
		}
	}
}


TimeSpan!(T, Unit.millisecond) milliseconds(T)(T count) {
	TimeSpan!(T, Unit.millisecond) t;
	t.milliseconds = count;
	return t;
}
TimeSpan!(T, Unit.second) seconds(T)(T count) {
	TimeSpan!(T, Unit.second) t;
	t.seconds = count;
	return t;
}
TimeSpan!(T, Unit.minute) minutes(T)(T count) {
	TimeSpan!(T, Unit.minute) t;
	t.minutes = count;
	return t;
}
TimeSpan!(T, Unit.hour) hours(T)(T count) {
	TimeSpan!(T, Unit.hour) t;
	t.hours = count;
	return t;
}
TimeSpan!(T, Unit.day) days(T)(T count) {
	TimeSpan!(T, Unit.day) t;
	t.days = count;
	return t;
}

unittest {
//	assert(seconds(10) + minutes(1) == seconds(70));
	
	auto t = seconds(70);
	assert(seconds(10) + minutes(1) == t);
	assert(minutes(1) + seconds(10) == t);
	
	auto t2 = seconds(50);
	assert(minutes(1) - seconds(10) == t2);
}


struct UtcDateTime(T = d_time, Unit unit = Unit.tick) {
	// Time span since epoch
	TimeSpan!(T, unit) span;
	
	// The length in each unit since epoch.
	alias span.ticks ticks;
	alias span.milliseconds milliseconds;
	alias span.seconds seconds;
	alias span.minutes minutes;
	alias span.hours hours;
	alias span.days days;
	
	// The truncated value for each unit (seconds can never exceed 60)
	T millisecond() { return span.milliseconds % 1000; }
	T second() { return span.seconds % 60; }
	T minute() { return span.minutes % 60; }
	T hour() { return span.hours % 24; }
	T day() { return span.days; }
	
	// UTC Offset, always zero.
	enum offset = TimeSpan!(short, Unit.minute)();
}

struct DateTime(T = d_time, Unit unit = Unit.tick) {
	// Time span since epoch
	TimeSpan!(T, unit) span;
	
	// The length in each unit since epoch.
	alias span.ticks ticks;
	alias span.milliseconds milliseconds;
	alias span.seconds seconds;
	alias span.minutes minutes;
	alias span.hours hours;
	alias span.days days;
	
	// The truncated value for each unit (seconds can never exceed 60)
	T millisecond() { return span.milliseconds % 1000; }
	T second() { return span.seconds % 60; }
	T minute() { return span.minutes % 60; }
	T hour() { return span.hours % 24; }
	T day() { return span.days; }
	
	// UTC Offset
	TimeSpan!(short, Unit.minute) offset;
}

alias UtcDateTime!(int, Unit.tick) UtcTime;
alias DateTime!(int, Unit.tick) Time;

alias UtcDateTime!(int, Unit.day) UtcDate;
alias DateTime!(int, Unit.day) Date;

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Apr 27 2010
parent reply SHOO <zan77137 nifty.com> writes:
Michel Fortin さんは書きました:

 On 2010-04-27 04:55:28 -0400, SHOO <zan77137 nifty.com> said:
 

 By these reasons, I made std.time module as the first step of the
 contribution for Phobos.


 
 Looks nice. I think defining structs as you did to handle date and time 
 is the way to go.
 
 I've done something similar in the past to store dates and times which I 
 like a lot. What I did was just a storage format, but templates allowed 
 me to store dates and time spans with any precision while exposing 
 always the same public API.
 
 I'm pasting my code below in case it can inspire you (note that this 
 code predates the new operator overloading syntax), and feel free to use 
 any of this under the Boost license if applicable.


In the code that I wrote, it can express Time until December 31, 9999. 
And, the precision of Span is 100 nanoseconds order.
About the precision, I think that it is necessary and sufficient condition.
But your idea is interesting. It seem to be more interesting if BigInt 
is combined.
Apr 27 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 27 Apr 2010 13:26:25 -0400, SHOO <zan77137 nifty.com> wrote:


 Michel Fortin さんは書きました:

 On 2010-04-27 04:55:28 -0400, SHOO <zan77137 nifty.com> said:


 By these reasons, I made std.time module as the first step of the
 contribution for Phobos.


  Looks nice. I think defining structs as you did to handle date and  
 time is the way to go.
  I've done something similar in the past to store dates and times which  
 I like a lot. What I did was just a storage format, but templates  
 allowed me to store dates and time spans with any precision while  
 exposing always the same public API.
  I'm pasting my code below in case it can inspire you (note that this  
 code predates the new operator overloading syntax), and feel free to  
 use any of this under the Boost license if applicable.


 In the code that I wrote, it can express Time until December 31, 9999.  
 And, the precision of Span is 100 nanoseconds order.
 About the precision, I think that it is necessary and sufficient  
 condition.


Two other benefits to using 100NS increments: Windows FILETIME structures  
use that same resolution, and Tango uses that same resolution.  So we have  
easy compatibility throughout many systems, while at the same time  
capturing a wide enough range to last for 8000 years :)

-Steve
Apr 27 2010
parent Sean Kelly <sean invisibleduck.org> writes:
Steven Schveighoffer Wrote:

 
 Two other benefits to using 100NS increments: Windows FILETIME structures  
 use that same resolution, and Tango uses that same resolution.  So we have  
 easy compatibility throughout many systems, while at the same time  
 capturing a wide enough range to last for 8000 years :)


The core package in D2 uses that resolution as well.  It would be great if this
could be represented by a struct rather than a long int.
Apr 28 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 27 Apr 2010 04:55:28 -0400, SHOO <zan77137 nifty.com> wrote:


 Tango is great library for D1. I am Tango user and I am indebted to
 Tango well. But Tango has some probrems.

 - Tango's license is BSD lisence or AFL. This license is incompatible to
 Phobos's Boost license.
 - The specification is disregarded, for example Object.dispose and  
 string.
 - Tango supports only D1
 - In particular, deep regret is to have split resources of D into two
 halves.

 If possible, I want to migrate to D2. And I want to be separated from
 Tango. However, some functions are insufficient for Phobos compared with
 Tango.
 The std.date module is one of the list of dissatisfaction to Phobos.
 I summarize my (and some of Japanese users's) opinion following:

 - I want to handle it as another thing for the time and the time span.
 - I want a more structural class for time operating.
 - std.date is a bit buggy...

 By these reasons, I made std.time module as the first step of the
 contribution for Phobos.


I like what you've done.  It's very similar to what was done in Tango.  I  
hate to ask this, but I just want to verify that you did not base your  
code on Tango, especially since you have used Tango.  I was planning to  
implement a Time system for Tango that mimics Tango's design, if that is  
what you have done, I think that's perfectly legit.  Basically, I want to  
verify that you rewrote all your implementation from scratch.

More comments:

I'd like accessors for seconds/milliseconds/etc from Span.

I'm not sure I like the Clocks structure.  Why have a separate Span that  
is in terms of some arbitrary OS resolution?  Can you give an example of  
why I'd want to use Clocks instead of Span?

-Steve
Apr 27 2010
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 27 Apr 2010 10:50:34 -0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 I was planning to implement a Time system for Tango that mimics Tango's  
 design


I meant implement a Time system for *Phobos* that mimics Tango's design.

Duh, me need more brain.

-Steve
Apr 27 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 I like what you've done.  It's very similar to what was done in Tango.  I  
 hate to ask this, but I just want to verify that you did not base your  
 code on Tango, especially since you have used Tango.


In D2 the runtime of Phobos and Tango have being merged, so all D programmers
can install both libs. So the two libs must have distinct contents.
So I'm for removing the time module from Phobos, and keep only the Tango one.
So this module is waste of time, and efforts have to be redirected in improving
or rewriting the time module of Tango.
Othrwise in D2 it will happen the same mess it's happend in D1, where you have
two partially duplicated libs. All D2 programmers will want to install both
libs, and they will not desire to choose what time lib to use. One time lit is
enough.

Bye,
bearophile
Apr 27 2010
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tue, Apr 27, 2010 at 10:58:33AM -0400, bearophile wrote:

 So I'm for removing the time module from Phobos, and keep only the Tango one.
So this module is waste of time, and efforts have to be redirected in improving
or rewriting the time module of Tango.


Tango is unacceptable for use for a lot of us, due to the license. The
more in Phobos, licensed that way, the better. That's the stuff everybody
can use.

-- 
Adam D. Ruppe
http://arsdnet.net
Apr 27 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-04-27 10:58:33 -0400, bearophile <bearophileHUGS lycos.com> said:


 In D2 the runtime of Phobos and Tango have being merged, so all D 
 programmers can install both libs. So the two libs must have distinct 
 contents.
 So I'm for removing the time module from Phobos, and keep only the 
 Tango one. So this module is waste of time, and efforts have to be 
 redirected in improving or rewriting the time module of Tango.
 Othrwise in D2 it will happen the same mess it's happend in D1, where 
 you have two partially duplicated libs. All D2 programmers will want to 
 install both libs, and they will not desire to choose what time lib to 
 use. One time lit is enough.


Tango's license is more restrictive than Phobos. It might not be a 
concern to you, but this is one reason someone might not want to use 
Tango in a project. Saying everyone will always want to use both libs 
is a little too much optimistic in my opinion. Phobos isn't using the 
Boost license for nothing.

About the mess, as long as both libraries run on the same runtime, the 
problems should be confined to writing conversion function to convert 
the data types that differs between the two libraries. I don't think 
this is anything to worry about: those things happens all the time when 
you're using libraries from different sources.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Apr 27 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Michel Fortin:


I don't think this is anything to worry about: those things happens all the
time when you're using libraries from different sources.<


Thank you for your answer.
A little community of people writing for the same nearly unknown language two
different standard libraries that share lot of functionality. I don't remember
other uncommon (or even common) languages in this situation :-) Even if I can
accept that there is no solution, I will never see this as something normal or
sane :-)

Bye,
bearophile
Apr 27 2010
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tue, Apr 27, 2010 at 12:12:36PM -0400, bearophile wrote:

 A little community of people writing for the same nearly unknown language two
different standard libraries that share lot of functionality. I don't remember
other uncommon (or even common) languages in this situation :-) Even if I can
accept that there is no solution, I will never see this as something normal or
sane :-)


I'm sure it happens all the time in uncommon languages, but you don't hear
about them because they are uncommon!

For a common language example, look no further than C.

-- 
Adam D. Ruppe
http://arsdnet.net
Apr 27 2010
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On 04/27/2010 04:58 PM, bearophile wrote:

 Steven Schveighoffer:

 I like what you've done.  It's very similar to what was done in Tango.  I
 hate to ask this, but I just want to verify that you did not base your
 code on Tango, especially since you have used Tango.


 In D2 the runtime of Phobos and Tango have being merged, so all D programmers
can install both libs. So the two libs must have distinct contents.
 So I'm for removing the time module from Phobos, and keep only the Tango one.
So this module is waste of time, and efforts have to be redirected in improving
or rewriting the time module of Tango.
 Othrwise in D2 it will happen the same mess it's happend in D1, where you have
two partially duplicated libs. All D2 programmers will want to install both
libs, and they will not desire to choose what time lib to use. One time lit is
enough.


I don't think anyone should have to install an extra library just to 
figure out what time it is.

-Lars
Apr 27 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Lars T. Kyllingstad:

 I don't think anyone should have to install an extra library just to 
 figure out what time it is.


I agree. But months ago I have though that a basic&standard D2 installation
will already contain both libs. I guess I was wrong.

Bye,
bearophile
Apr 27 2010
parent SHOO <zan77137 nifty.com> writes:
bearophile $B$5$s$O=q$-$^$7$?(B:

 Lars T. Kyllingstad:

 I don't think anyone should have to install an extra library just to 
 figure out what time it is.


 
 I agree. But months ago I have though that a basic&standard D2 installation
will already contain both libs. I guess I was wrong.
 
 Bye,
 bearophile


Really, if Tango had solved the license problem and been able to be used
for D2, I would be happy.
Apr 27 2010
prev sibling next sibling parent SHOO <zan77137 nifty.com> writes:
bearophile $B$5$s$O=q$-$^$7$?(B:

 Steven Schveighoffer:

 I like what you've done.  It's very similar to what was done in Tango.  I  
 hate to ask this, but I just want to verify that you did not base your  
 code on Tango, especially since you have used Tango.


 
 In D2 the runtime of Phobos and Tango have being merged, so all D programmers
can install both libs. So the two libs must have distinct contents.
 So I'm for removing the time module from Phobos, and keep only the Tango one.
So this module is waste of time, and efforts have to be redirected in improving
or rewriting the time module of Tango.
 Othrwise in D2 it will happen the same mess it's happend in D1, where you have
two partially duplicated libs. All D2 programmers will want to install both
libs, and they will not desire to choose what time lib to use. One time lit is
enough.
 
 Bye,
 bearophile


You are right. However, I cannot follow the most recent version of D as
far as unfortunately I am going to use Tango.
Apr 27 2010
prev sibling parent Bernard Helyer <b.helyer gmail.com> writes:
On 28/04/10 02:58, bearophile wrote:

 Steven Schveighoffer:

 I like what you've done.  It's very similar to what was done in Tango.  I
 hate to ask this, but I just want to verify that you did not base your
 code on Tango, especially since you have used Tango.


 In D2 the runtime of Phobos and Tango have being merged, so all D programmers
can install both libs. So the two libs must have distinct contents.
 So I'm for removing the time module from Phobos, and keep only the Tango one.
So this module is waste of time, and efforts have to be redirected in improving
or rewriting the time module of Tango.
 Othrwise in D2 it will happen the same mess it's happend in D1, where you have
two partially duplicated libs. All D2 programmers will want to install both
libs, and they will not desire to choose what time lib to use. One time lit is
enough.

 Bye,
 bearophile


I take it then, that you are offering to port Tango to D2? That's very 
sporting of you!

If not, then don't speak of using Tango, as it can not be used with D2 
today, and SHOO's std.time can. Which makes std.time vastly more useful 
than Tango's classes. We need a decent date and time module for D2 right 
*now*, not in a speculative future.
Apr 27 2010
prev sibling parent reply SHOO <zan77137 nifty.com> writes:
Steven Schveighoffer さんは書きました:

 On Tue, 27 Apr 2010 04:55:28 -0400, SHOO <zan77137 nifty.com> wrote:
 

 Tango is great library for D1. I am Tango user and I am indebted to
 Tango well. But Tango has some probrems.

 - Tango's license is BSD lisence or AFL. This license is incompatible to
 Phobos's Boost license.
 - The specification is disregarded, for example Object.dispose and 
 string.
 - Tango supports only D1
 - In particular, deep regret is to have split resources of D into two
 halves.

 If possible, I want to migrate to D2. And I want to be separated from
 Tango. However, some functions are insufficient for Phobos compared with
 Tango.
 The std.date module is one of the list of dissatisfaction to Phobos.
 I summarize my (and some of Japanese users's) opinion following:

 - I want to handle it as another thing for the time and the time span.
 - I want a more structural class for time operating.
 - std.date is a bit buggy...

 By these reasons, I made std.time module as the first step of the
 contribution for Phobos.


 
 I like what you've done.  It's very similar to what was done in Tango.  
 I hate to ask this, but I just want to verify that you did not base your 
 code on Tango, especially since you have used Tango.  I was planning to 
 implement a Time system for Tango that mimics Tango's design, if that is 
 what you have done, I think that's perfectly legit.  Basically, I want 
 to verify that you rewrote all your implementation from scratch.


I wrote it by own hand.
But I referred to Tango, Phobos or some web site some interfaces and 
physical quantities(The thing which becomes the same quantity even if 
anyone calculates).

Please point out the point where you noticed.


 More comments:
 
 I'd like accessors for seconds/milliseconds/etc from Span.


For integer?
I dislike that precision is cut off.
You can get seconds with a real number in interval, or calculate by 
ticks and TICKSPERSEC.


 I'm not sure I like the Clocks structure.  Why have a separate Span that 
 is in terms of some arbitrary OS resolution?  Can you give an example of 
 why I'd want to use Clocks instead of Span?
 
 -Steve


Clocks.TICKSPERSEC may have better precision than Span.TICKSPERSEC.
Sacrificing precision in the middle of a calculation is MOTTAINAI.
Clocks may be used for benchmarks or exact time measurement.
Apr 27 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 27 Apr 2010 12:32:44 -0400, SHOO <zan77137 nifty.com> wrote:


 Steven Schveighoffer さんは書きました:

 On Tue, 27 Apr 2010 04:55:28 -0400, SHOO <zan77137 nifty.com> wrote:


 Tango is great library for D1. I am Tango user and I am indebted to
 Tango well. But Tango has some probrems.

 - Tango's license is BSD lisence or AFL. This license is incompatible  
 to
 Phobos's Boost license.
 - The specification is disregarded, for example Object.dispose and  
 string.
 - Tango supports only D1
 - In particular, deep regret is to have split resources of D into two
 halves.

 If possible, I want to migrate to D2. And I want to be separated from
 Tango. However, some functions are insufficient for Phobos compared  
 with
 Tango.
 The std.date module is one of the list of dissatisfaction to Phobos.
 I summarize my (and some of Japanese users's) opinion following:

 - I want to handle it as another thing for the time and the time span.
 - I want a more structural class for time operating.
 - std.date is a bit buggy...

 By these reasons, I made std.time module as the first step of the
 contribution for Phobos.


  I like what you've done.  It's very similar to what was done in  
 Tango.  I hate to ask this, but I just want to verify that you did not  
 base your code on Tango, especially since you have used Tango.  I was  
 planning to implement a Time system for Tango that mimics Tango's  
 design, if that is what you have done, I think that's perfectly legit.   
 Basically, I want to verify that you rewrote all your implementation  
 from scratch.


 I wrote it by own hand.
 But I referred to Tango, Phobos or some web site some interfaces and  
 physical quantities(The thing which becomes the same quantity even if  
 anyone calculates).

 Please point out the point where you noticed.


If you wrote it by your own hand and only used interfaces for guidance,  
then I think it is free and clear from copyright issues.  Thanks for  
clarifying!


 More comments:
  I'd like accessors for seconds/milliseconds/etc from Span.


 For integer?
 I dislike that precision is cut off.
 You can get seconds with a real number in interval, or calculate by  
 ticks and TICKSPERSEC.


The internal storage is via integer, so if for example the integer number  
of milliseconds is desired, doing the calculation via converting to a  
floating point, and then scaling/truncating is inefficient, subject to  
floating point error, and more convoluted than it has to be.  I'd rather  
have an exact method that is as fast as possible, and is as simple as  
possible.  It is not too much extra to add these methods (they are pretty  
much boilerplate code).

Many existing C libraries and network protocols encode time via integers,  
so there is real need to be able to convert to these units, and to allow  
it with as little syntax as possible is good.


 I'm not sure I like the Clocks structure.  Why have a separate Span  
 that is in terms of some arbitrary OS resolution?  Can you give an  
 example of why I'd want to use Clocks instead of Span?
  -Steve


 Clocks.TICKSPERSEC may have better precision than Span.TICKSPERSEC.
 Sacrificing precision in the middle of a calculation is MOTTAINAI.
 Clocks may be used for benchmarks or exact time measurement.


Ah, I didn't think that Clocks.TICKSPERSEC could have *better* resolution,  
that is a good benefit.

Then all that is left is the name, Clocks is not a good name for a value  
type entity.  It seems more suited for a static entity that contains  
clocks.  You already have defined interval, so that is out.  I can't think  
of anything good right now, but it definitely should not be a plural word.

This is a very solid library, very little to complain about!

One thing I would suggest if this is assimilated into druntime/phobos is  
that we split the Span functionality out into it's own module (or put it  
in object.di) so it can be used in druntime for things like Thread.sleep.

-Steve
Apr 27 2010
next sibling parent SHOO <zan77137 nifty.com> writes:
Steven Schveighoffer さんは書きました:

 On Tue, 27 Apr 2010 12:32:44 -0400, SHOO <zan77137 nifty.com> wrote:



 The internal storage is via integer, so if for example the integer 
 number of milliseconds is desired, doing the calculation via converting 
 to a floating point, and then scaling/truncating is inefficient, subject 
 to floating point error, and more convoluted than it has to be.  I'd 
 rather have an exact method that is as fast as possible, and is as 
 simple as possible.  It is not too much extra to add these methods (they 
 are pretty much boilerplate code).
 Many existing C libraries and network protocols encode time via 
 integers, so there is real need to be able to convert to these units, 
 and to allow it with as little syntax as possible is good.


Even if there are Span.seconds, Span.mseconds...etc., it is not strange. 
In addition, it give the symmetry with seconds, mseconds ...etc.
I'm getting the feeling that the one that there are not the methods is 
strange than there are.
I'll try it.



 Then all that is left is the name, Clocks is not a good name for a value 
 type entity.  It seems more suited for a static entity that contains 
 clocks.  You already have defined interval, so that is out.  I can't 
 think of anything good right now, but it definitely should not be a 
 plural word.
 
 This is a very solid library, very little to complain about!


I have sense of incongruity for a name of Clocks. But good ideas about 
the name did not appear. Do you have any ideas? >ALL


 One thing I would suggest if this is assimilated into druntime/phobos is 
 that we split the Span functionality out into it's own module (or put it 
 in object.di) so it can be used in druntime for things like Thread.sleep.


It's nice.
Thread.sleep confuses me a little because the argument's number of 
digits is too big.
I hope so strongly.


 -Steve
Apr 28 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vbtz2wngeav7ka localhost.localdomain...

 Then all that is left is the name, Clocks is not a good name for a value 
 type entity.  It seems more suited for a static entity that contains 
 clocks.  You already have defined interval, so that is out.  I can't think 
 of anything good right now, but it definitely should not be a plural word.


Ticks?
Apr 30 2010
prev sibling parent reply SHOO <zan77137 nifty.com> writes:
SHOO $B$5$s$O=q$-$^$7$?(B:

 I make std.time module for Phobos. This module provides Time, Span,
 Clock, StopWatch and some utility functions for time operation.
 I hope combine this module to Phobos instead of std.date.
 
 download is here:
 	http://j.mp/95aS1K (== http://dusers.dip.jp/ ... /time.d)
 	http://j.mp/9p5DDu (patch for Phobos's trunk r1481)
 	http://ideone.com/eiQ19 (for code view)
 
 Besides, is there the necessary function? (This module lacks the
 daylight saving time handling, because of a lack of my understanding.)
 
 
 I talk about the process that reached making...
 
 Tango is great library for D1. I am Tango user and I am indebted to
 Tango well. But Tango has some probrems.
 
 - Tango's license is BSD lisence or AFL. This license is incompatible to
 Phobos's Boost license.
 - The specification is disregarded, for example Object.dispose and string.
 - Tango supports only D1
 - In particular, deep regret is to have split resources of D into two
 halves.
 
 If possible, I want to migrate to D2. And I want to be separated from
 Tango. However, some functions are insufficient for Phobos compared with
 Tango.
 The std.date module is one of the list of dissatisfaction to Phobos.
 I summarize my (and some of Japanese users's) opinion following:
 
 - I want to handle it as another thing for the time and the time span.
 - I want a more structural class for time operating.
 - std.date is a bit buggy...
 
 By these reasons, I made std.time module as the first step of the
 contribution for Phobos.


Too late to update std.time, but...


My old code was represented infringing Tango's license.
(See:
http://www.digitalmars.com/d/archives/digitalmars/D/announce/Masahiro_Nakagawa_and_SHOO_invited_to_join_Phobos_developers_18108.html
)


Therefore, I checked and rewrote some codes for excluding code that may
infringe Tango.

This: http://ideone.com/M2zB7

I checked it carefully. And I clarified an origin of source of all
cords. (Check "Note:" tags.)
I hereby made clear that this module does not include the cord which
infringes Tango.

The interface referred to ptime and time_duration of Boost. (I think
others are rather complicating for standard library.)
By this reason, I changed some names. (Span to Duration)

If this contribution is turned down, I give up std.time.
May 13 2010
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
(Note that SHOO means "code" where he says "cord".  "Code" and "cord"
are both $B%3!<%I(B in Japanese, so it's easy for Japanese folks to get the
two words mixed up.)

--bb

2010/5/13 SHOO <zan77137 nifty.com>:

 SHOO $B$5$s$O=q$-$^$7$?(B:

 I make std.time module for Phobos. This module provides Time, Span,
 Clock, StopWatch and some utility functions for time operation.
 I hope combine this module to Phobos instead of std.date.

 download is here:
       http://j.mp/95aS1K (== http://dusers.dip.jp/ ... /time.d)
       http://j.mp/9p5DDu (patch for Phobos's trunk r1481)
       http://ideone.com/eiQ19 (for code view)

 Besides, is there the necessary function? (This module lacks the
 daylight saving time handling, because of a lack of my understanding.)


 I talk about the process that reached making...

 Tango is great library for D1. I am Tango user and I am indebted to
 Tango well. But Tango has some probrems.

 - Tango's license is BSD lisence or AFL. This license is incompatible to
 Phobos's Boost license.
 - The specification is disregarded, for example Object.dispose and string.
 - Tango supports only D1
 - In particular, deep regret is to have split resources of D into two
 halves.

 If possible, I want to migrate to D2. And I want to be separated from
 Tango. However, some functions are insufficient for Phobos compared with
 Tango.
 The std.date module is one of the list of dissatisfaction to Phobos.
 I summarize my (and some of Japanese users's) opinion following:

 - I want to handle it as another thing for the time and the time span.
 - I want a more structural class for time operating.
 - std.date is a bit buggy...

 By these reasons, I made std.time module as the first step of the
 contribution for Phobos.


 Too late to update std.time, but...


 My old code was represented infringing Tango's license.
 (See:
 http://www.digitalmars.com/d/archives/digitalmars/D/announce/Masahiro_Nakagawa_and_SHOO_invited_to_join_Phobos_developers_18108.html
 )


 Therefore, I checked and rewrote some codes for excluding code that may
 infringe Tango.

 This: http://ideone.com/M2zB7

 I checked it carefully. And I clarified an origin of source of all
 cords. (Check "Note:" tags.)
 I hereby made clear that this module does not include the cord which
 infringes Tango.

 The interface referred to ptime and time_duration of Boost. (I think
 others are rather complicating for standard library.)
 By this reason, I changed some names. (Span to Duration)

 If this contribution is turned down, I give up std.time.
May 13 2010
parent SHOO <zan77137 nifty.com> writes:
Bill Baxter $B$5$s$O=q$-$^$7$?(B:

 (Note that SHOO means "code" where he says "cord".  "Code" and "cord"
 are both $B%3!<%I(B in Japanese, so it's easy for Japanese folks to get the
 two words mixed up.)
 


Oops, I'm embarrassing!
And thanks for your help.
May 14 2010
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 13 May 2010 10:42:56 -0400, SHOO <zan77137 nifty.com> wrote:


 Therefore, I checked and rewrote some codes for excluding code that may
 infringe Tango.


I don't know if this will be enough, I wish I could tell you different.   
Can you identify which functions you rewrote from the original proposal to  
help focus Tango's attention?

Is there anyone listening from Tango who can check this against Tango code  
to see if you still consider it to be infringing?


 If this contribution is turned down, I give up std.time.


First, I hope this can be included, it looks like very solid code.   
Second, if it cannot be included, I hope this does not dissuade you from  
contributing to Phobos for other modules.

-Steve
May 13 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:

 First, I hope this can be included, it looks like very solid code.  
 Second, if it cannot be included, I hope this does not dissuade you from 
 contributing to Phobos for other modules.



Basically, the next time there's a suggestion of infringement from anyone, I'd 
like a specific list of the lines of source that are infringing. I don't think 
there's any reasonable way to deal with it otherwise. It shouldn't be necessary 
to guess what those lines might be.
May 13 2010
next sibling parent SHOO <zan77137 nifty.com> writes:
Walter Bright さんは書きました:

 Steven Schveighoffer wrote:

 First, I hope this can be included, it looks like very solid code.  
 Second, if it cannot be included, I hope this does not dissuade you 
 from contributing to Phobos for other modules.


 
 
 Basically, the next time there's a suggestion of infringement from 
 anyone, I'd like a specific list of the lines of source that are 
 infringing. I don't think there's any reasonable way to deal with it 
 otherwise. It shouldn't be necessary to guess what those lines might be.


I think so, too.
At least, I cannot work around hearsay suggestions accurately.
I cannot know where/who I ask it.
May 14 2010
prev sibling parent reply retard <re tard.com.invalid> writes:
Thu, 13 May 2010 14:37:58 -0700, Walter Bright wrote:


 Steven Schveighoffer wrote:

 First, I hope this can be included, it looks like very solid code.
 Second, if it cannot be included, I hope this does not dissuade you
 from contributing to Phobos for other modules.


 
 
 Basically, the next time there's a suggestion of infringement from
 anyone, I'd like a specific list of the lines of source that are
 infringing. I don't think there's any reasonable way to deal with it
 otherwise. It shouldn't be necessary to guess what those lines might be.


You can have long lasting legal battles even without clearly specifying 
the infringing lines of code. You've probably heard of SCO (a Microsoft's 
sockpuppet company) and the claims about origins of infringing UNIX/Linux 
kernel (version 2.7) code. That's also how patent FUD works. They say 
that Linux infringes 107 instances of their intellectual property gems, 
i.e. patents.
May 14 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 14 May 2010 21:01:10 -0400, retard <re tard.com.invalid> wrote:


 Thu, 13 May 2010 14:37:58 -0700, Walter Bright wrote:


 Steven Schveighoffer wrote:

 First, I hope this can be included, it looks like very solid code.
 Second, if it cannot be included, I hope this does not dissuade you
 from contributing to Phobos for other modules.



 Basically, the next time there's a suggestion of infringement from
 anyone, I'd like a specific list of the lines of source that are
 infringing. I don't think there's any reasonable way to deal with it
 otherwise. It shouldn't be necessary to guess what those lines might be.


 You can have long lasting legal battles even without clearly specifying
 the infringing lines of code. You've probably heard of SCO (a Microsoft's
 sockpuppet company) and the claims about origins of infringing UNIX/Linux
 kernel (version 2.7) code. That's also how patent FUD works. They say
 that Linux infringes 107 instances of their intellectual property gems,
 i.e. patents.


In SCO's case, they did not want to reveal the lines because they would  
then be publishing that source without a license.  Personally, I think  
it's because they knew they had no case.

And SCO has 0 patent infringement claims in their lawsuits.

In this case, both Tango and Phobos are open source, there is no reason to  
keep secret the lines of code that are infringing.  And I don't anticipate  
that Tango or Walter are interested in having legal battles, what is there  
to gain?  I think it's reasonable that if someone from Tango or Phobos  
things there is unlicensed copying, they come forth with evidence instead  
of suspicion.

-Steve
May 14 2010
prev sibling parent SHOO <zan77137 nifty.com> writes:
Steven Schveighoffer さんは書きました:

 On Thu, 13 May 2010 10:42:56 -0400, SHOO <zan77137 nifty.com> wrote:
 
 I don't know if this will be enough, I wish I could tell you different.  
 Can you identify which functions you rewrote from the original proposal 
 to help focus Tango's attention?
 


http://ideone.com/TZ3Bi

- I specified my real name for "Author:" tag.
- Renamed Span to Duration.
- Added Duration.seconds, Duration.mseconds, Duration.useconds, 
Duration.nseconds.
- Wrote "Note:" tags and comments for assertion of infringement-free.
- Rewrote EPOCH1970(This becomes the same quantity even if anyone 
calculates, but just to be safe) by own hand newly
- Rewrote Date.isLeapYear by own hand newly (I wrote old isLeapYear by 
own hand too. However, by a check, I confirmed that it was the same as 
Tango's code.)
- Added some unittest codes
- Fixed iso8601 format, "yyyy-mm-dd hh:mm:ss,sss" to 
"yyyy-mm-ddThh:mm:ss,sss"
- Renamed Clocks to Ticks
- Added Ticks.seconds, Ticks.mseconds, Ticks.useconds, Ticks.nseconds.
- Clocks.span to Clocks.duration



 Is there anyone listening from Tango who can check this against Tango 
 code to see if you still consider it to be infringing?
 

 If this contribution is turned down, I give up std.time.


 
 First, I hope this can be included, it looks like very solid code.  
 Second, if it cannot be included, I hope this does not dissuade you from 
 contributing to Phobos for other modules.
 
 -Steve


Thanks. But don't worry.
My next challenge only begins even if it became the second situation.
May 14 2010