Feature #4068: Replace current standard Date/DateTime library with home_run

• Status: Rejected
• Assignee: tadf (tadayoshi funaba)
• Target version: -

[jeremyevans0 (Jeremy Evans)]

=begin
The current standard date library is slow enough to be the bottleneck in many programs. I have written a replacement for it in C (named home_run) that is much faster while attempting to be mostly compatible. I open this ticket in the hope that home_run can replace the current standard date library in a future version of ruby.

First, the code is at: https://github.com/jeremyevans/home_run

As it states in the README, here are the known differences from the current standard library:

• Written in C (mostly) instead of ruby. Stores information in a C structure, and therefore has a range limitation. home_run cannot handle dates after 5874773-08-15 or before -5877752-05-08 on 32-bit platforms (with larger limits for 64-bit platforms).
• The Date class does not store fractional days (e.g. hours, minutes), or offsets. The DateTime class does handle fractional days and offsets.
• The DateTime class stores fractional days as the number of nanoseconds since midnight, so it cannot deal with differences less than a nanosecond.
• Neither Date nor DateTime uses rational. Places where the standard library returns rationals, home_run returns integers or floats.
• Because rational is not used, it is not required. This can break other libraries that use rational without directly requiring it.
• There is no support for modifying the date of calendar reform, the sg arguments are ignored and the Gregorian calendar is always used. This means that julian day 0 is -4173-11-24, instead of -4712-01-01.
• The undocumented Date#strftime format modifiers are not supported.
• The DateTime offset is checked for reasonableness. home_run does not support offsets with an absolute difference of more than 14 hours from UTC.
• DateTime offsets are stored in minutes, so it will round offsets with fractional minutes to the nearest minute.
• All public class and instance methods for both Date and DateTime are implemented, except that the allocate class method is not available and on 1.9, _dump and _load are used instead of marshal_dump and marshal_load.
• Only the public API is compatible, the private methods in the standard library are not implemented.
• The marshalling format differs from the one used by the standard library. Note that the 1.8 and 1.9 standard library date marshalling formats differ from each other.
• Date#step treats the step value as an integer, so it cannot handle steps of fractional days. DateTime#step can handle fractional day steps, though.
• When parsing the %Q modifier in _strptime, the hash returned includes an Integer :seconds value and a Float :sec_fraction value instead of a single rational :seconds value.
• The string returned by #inspect has a different format, since it doesn't use rational.
• The conversion of 2-digit years to 4-digit years in Date._parse is set to true by default. On ruby 1.8, the standard library has it set to false by default.
• You can use the Date::Format::STYLE hash to change how to parse DD/DD/DD and DD.DD.DD date formats, allowing you to get ruby 1.9 behavior on 1.8 or vice-versa. This is probably the only new feature in that isn't in the standard library.

From previous discussions on ruby-core, the following things will probably need to be changed before home_run could replace the current standard date library:

• The marshalling format needs to be made compatible with the current standard library.
• The specs needs to be converted from MSpec to minitest/spec for inclusion in ruby.
• The RubySpec project also needs to have the MSpecs added, with the appropriate version guards where behavior has changed.
• Where home_run now returns floats, it should return rationals instead.

I'm willing to make these changes and other reasonable changes in order to get this included in ruby. I just need to know what all of the required changes are.
=end

[shyouhei (Shyouhei Urabe)]

• Status changed from Open to Assigned

=begin

=end

[naruse (Yui NARUSE)]

=begin
This topic is from [ruby-core:32248].
=end

[tadf (tadayoshi funaba)]

• Priority changed from Normal to 3

=begin
home_run seems to wanna be an imitation of Time.
i'll recommend most of user of Date to use Time with ruby 1.9.2 rather than your library.
i know most of user of Date (or DateTime) really wished complete Time which has no restrictions.
it's too bad.
because, i wrote Date (date2), not an imitation of Time.
it has rich functions.
i don't know why we should remove them now.
Time already has no year 2038 issue.
=end

[jeremyevans0 (Jeremy Evans)]

=begin
home_run is not at all about imitating Time. If you want some background on home_run and what problems it attempts to solve, please see my RubyConf presentation: http://jeremyevans-pres.heroku.com/rc2010_presentation/img1.html.

I agree that in most cases using 1.9.2+, Time is better than DateTime, but Time is not comparable to Date at all. If you want to deal with dates without times, then you should use Date and not Time.

home_run implements all of Date's API, other than the differences mentioned in this ticket's description, so I'm not sure which "rich functions" you are referring to that are currently implemented by the standard date library that are not implemented by home_run. If you mention these specifically, it's always possible that they could be added.

It would be very much preferable to have either one of the following happen:

1. A flat out rejection of having home_run replace the current date standard library, even if no explanation is given.
2. An agreement for having home_run replace the current date standard library, with specific conditions.

Leaving this ticket open with no indication about how to ready home_run for acceptance is the worst case.
=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:33303] [Ruby 1.9-Feature#4068] Replace current standard Date/DateTime library with home_run"
on Wed, 24 Nov 2010 02:12:10 +0900, Jeremy Evans [e-mail] writes:

|It would be very much preferable to have either one of the following happen:
|
|1) A flat out rejection of having home_run replace the current date standard library, even if no explanation is given.
|2) An agreement for having home_run replace the current date standard library, with specific conditions.
|
|Leaving this ticket open with no indication about how to ready home_run for acceptance is the worst case.

I also would like to hear the reason behind objection against
replacement, if home_run is compatible enough.

						matz.

=end

[tadf (tadayoshi funaba)]

=begin
i don't have any rights about such an agreement on the ruby development or distribution.
however, i have big doubt to adopt home_run.

$ cat p.rb
require 'date'
require 'date/delta'
a = DateTime.new(2000)
b = DateTime.new(2000,1,1, 0,1,0)
d = Date::Delta.parse('1 second / 3')
p 1000.times.inject(a){|s, | s + d}.strftime('%F %T %20N')

$ cat p-hr.rb
require 'home_run'
a = DateTime.new(2000)
b = DateTime.new(2000,1,1, 0,1,0)
p 1000.times.inject(a){|s, | s + Rational(1, 259200)}.strftime('%F %T %N')

$ ruby192 p.rb
"2000-01-01 00:05:33 33333333333333333333"

$ ruby192 p-hr.rb
"2000-01-01 00:05:33 333333000"

home_run breaks relations time instances and time intervals (differences).
api is not matter.

$ TZ=Asia/Tokyo irb192 -r date
main@192-20100818> RUBY_PLATFORM
#=> "x86_64-linux"
main@192-20100818> 0.size
#=> 8
main@192-20100818> t = Time.new(1800,1,1)
#=> 1800-01-01 00:00:00 +0919
main@192-20100818> dt = t.to_datetime
#=> #<DateTime: 1800-01-01T00:00:00+09:18 (205502064061/86400,33539/86400,2299161)>
main@192-20100818> dt.strftime('%::z')
#=> "+09:18:59"
main@192-20100818> dt.to_time
#=> 1800-01-01 00:00:00 +0919

$ TZ=Asia/Tokyo irb192 -r home_run
main@192-20100818> RUBY_PLATFORM
#=> "x86_64-linux"
main@192-20100818> 0.size
#=> 8
main@192-20100818> t = Time.new(1800,1,1)
#=> 1800-01-01 00:00:00 +0919
main@192-20100818> dt = t.to_datetime
#=> #<DateTime 1800-01-01T00:00:00+09:18>
main@192-20100818> dt.strftime('%::z')
#=> "::z"
main@192-20100818> dt.strftime('%z')
#=> "+0918"
main@192-20100818> dt.to_time
#=> 1800-01-01 00:00:59 +0919

Time is aware of them, but home_run is not.
so, should we accept this bad hop?

=end

[tadf (tadayoshi funaba)]

• File stolen_base.patch stolen_base.patch added

=begin
i have doubt to adopt home_run.
however, if we don't need luxury seat,
i'll propose yet another date library "stolen_base" which is based on built-in Time.
so, we don't need to have many similar implementations.
it does not have all methods yet, but it is pretty fast.

i've attached a patch (just 540 lines) to trunk (r29941).
try it.

this time, i've implemented them as built-in classes.
but i never wish to be built-ins.
it's only for simple implementation.

=end

[naruse (Yui NARUSE)]

=begin
Hi,

(2010/11/27 8:05), tadayoshi funaba wrote:

Issue #4068 has been updated by tadayoshi funaba.

i don't have any rights about such an agreement on the ruby development or distribution.
however, i have big doubt to adopt home_run.

...

home_run breaks relations time instances and time intervals (differences).
api is not matter.

...

Time is aware of them, but home_run is not.
so, should we accept this bad hop?

If home_run fixes this, you agree with home_run even if API compatibility is not fixed?

--
NARUSE, Yui [e-mail]

=end

[tadf (tadayoshi funaba)]

=begin
i'm sorry.
i have to say no.
bacause, stolen_base gives better results.

$ cat p-sb.rb
a = DateTime.new(2000)
b = DateTime.new(2000,1,1, 0,1,0)

p 1000.times.inject(a){|s, | s + Rational(1, 259200)}.strftime('%F %T %20N')

$ ruby p-sb.rb
"2000-01-01 00:05:33 33333333333333333333"

anyway, i can't believe he bends his design.
he want to avoid rational.

=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:33420] [Ruby 1.9-Feature#4068] Replace current standard Date/DateTime library with home_run"
on Sat, 27 Nov 2010 17:15:20 +0900, tadayoshi funaba [e-mail] writes:

|i'm sorry.
|i have to say no.
|bacause, stolen_base gives better results.

Well, define "better" here. You've said stolen_base (DateTime based
on Time) is "better". What does it mean? Better precision? Better
performance? Or Both?

I have a few questions for the community.

• If we have to pick one, which we should choose? Performance?
  Precision?

• Is there any possibility to achieve both performance and precision
  at the same time? Or stolen_base has already fast enough? Without
  sacrificing precision? Any benchmark?

  					matz.
  

=end

[tadf (tadayoshi funaba)]

=begin
the former.

stolen_base will accept what all of Time represents thing except zonename references and leapseconds.
in my experience, i suppose nearly all of users believe they do so naturally.

=end

[tadf (tadayoshi funaba)]

• File stolen_base.patch2 stolen_base.patch2 added
• File bm.rb bm.rb added

=begin
i've attached new patch and a script.

i tried to test some parts.

i admit home_run is fast.
however, stolen_base gives good results.
it's reasonable.
and stolen_base is faster on sort of array of DateTime.

home_run:
user system total real
Date::valid_date?: 0.020000 0.000000 0.020000 ( 0.022192)
Date::new: 0.050000 0.000000 0.050000 ( 0.047693)
Date#to_s: 0.100000 0.000000 0.100000 ( 0.098685)
Date#strftime: 0.290000 0.000000 0.290000 ( 0.287617)
[Date]#sort: 0.240000 0.000000 0.240000 ( 0.246225)
DateTime::new: 0.040000 0.000000 0.040000 ( 0.037280)
DateTime#to_s: 0.110000 0.000000 0.110000 ( 0.109193)
DateTime#strftime: 0.280000 0.000000 0.280000 ( 0.279418)
[DateTime]#sort: 1.080000 0.000000 1.080000 ( 1.083668)

stolen_base:
user system total real
Date::valid_date?: 0.040000 0.000000 0.040000 ( 0.043688)
Date::new: 0.210000 0.000000 0.210000 ( 0.202350)
Date#to_s: 0.170000 0.000000 0.170000 ( 0.168993)
Date#strftime: 0.340000 0.000000 0.340000 ( 0.340039)
[Date]#sort: 0.420000 0.000000 0.420000 ( 0.413603)
DateTime::new: 0.260000 0.000000 0.260000 ( 0.267269)
DateTime#to_s: 0.350000 0.000000 0.350000 ( 0.342907)
DateTime#strftime: 0.440000 0.000000 0.440000 ( 0.444539)
[DateTime]#sort: 0.450000 0.000000 0.450000 ( 0.445473)

i do not show the result of #today and #now.
bacause, they don't consider leapseconds of time_t.
it's unfair.

$ TZ=/usr/share/zoneinfo/right/Japan ruby193dev -r home_run -e 'puts [Time.now, DateTime.now, Time.now]'
2010-11-28 11:28:07 +0900
2010-11-28T11:28:31+09:00
2010-11-28 11:28:07 +0900

basically, stolen_base is nearly equal to Time on performance.
built-in Time is slow?
i've never heard such a report.

of course, we can delete and remove and cut the functions, then we will get faster one.
or an idea is a hybrid system like fixnum and bignum on numerical system.
however, i'm not sure, we want them really.

=end

[jeremyevans0 (Jeremy Evans)]

=begin
The reason for the difference in Tadayoshi's first example is because home_run has nanosecond level resolution.

The reason for the difference in Tadayoshi's second example is because home_run doesn't implement the undocumented strftime modifier options and because it stores the timezone offset in minutes.

The second example is easy to fix by falling back to the current date strftime code if one of the undocumented strftime modifier options is used, and by changing home_run to store the offset in seconds (or milliseconds) instead of minutes.

The first example is basically an inherent limitation in the design. However, it's one that I think most ruby programmers are willing to accept, as repeatably adding small amounts to DateTime objects is uncommon.

I have no problem with using stolen_base instead of home_run, at least for DateTime. I think one of the fundamental problems with the standard library is that Date objects are stored as DateTimes at midnight UTC. I think Date objects are fundamentally distinct from DateTimes, and that a Date object should store no time related data. The problem with Date objects storing time related data is shown in my RubyConf presentation:

http://jeremyevans-pres.heroku.com/rc2010_presentation/img40.html
http://jeremyevans-pres.heroku.com/rc2010_presentation/img46.html

Maybe stolen base could be implemented for DateTime, and home_run used as the basis for Date? I rarely use DateTime, my main focus with home_run was the performance of Date, with DateTime only added for compatibility. This hopefully wouldn't be difficult, as home_run already stores Date objects differently than it stores DateTime objects.

Tadayoshi, do you have any problem with how home_run implements Date (not DateTime)?

If there are issues with how home_run implements Date that can't be resolved, or if using home_run for Date and stolen_base for DateTime is considered too complex, I support stolen_base replacing the current standard Date/DateTime library.
=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:33440] [Ruby 1.9-Feature#4068] Replace current standard Date/DateTime library with home_run"
on Sun, 28 Nov 2010 10:28:49 +0900, tadayoshi funaba [e-mail] writes:

|stolen_base will accept what all of Time represents thing except zonename references and leapseconds.
|in my experience, i suppose nearly all of users believe they do so naturally.

I am not sure if we need to guarantee granularity less than a nano
second. Do we?

						matz.

=end

[tadf (tadayoshi funaba)]

=begin

I am not sure if we need to guarantee granularity less than a nano
second. Do we?

?? but, we already have

$ irb193dev -r time -r date
main@193-20101128> Time.parse('23:59.59.' + '9'*100).iso8601(100)
#=> "2010-11-28T23:59:59.9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999+09:00"
main@193-20101128> DateTime.parse('23:59.59.' + '9'*100).iso8601(100)
#=> "2010-11-28T23:59:59.9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999+00:00"

=end

[tadf (tadayoshi funaba)]

=begin
i'll welcome you if you support stolen_base with me.
however, i think we will need support of matz and akr who is the maintainer of Time firstly.

=end

[akr (Akira Tanaka)]

=begin
2010/11/28 tadayoshi funaba [e-mail]:

I am not sure if we need to guarantee granularity less than a nano
second. Do we?

?? but, we already have

I used Time to represent struct bintime in FreeBSD.
ext/socket/ancdata.c instantiates Time object from datagram timestamp which
contains struct bintime.
struct bintime can represent 2**-64 second.
http://phk.freebsd.dk/pubs/timecounter.pdf

Also, I found recent DB2 provides picosecond in TIMESTAMP.
If someone try to implement a binding for DB2,
nanosecond precision object is not satisfactory.

Tanaka Akira

=end

[Eregon (Benoit Daloze)]

=begin
Hi Matz,

On 27 November 2010 15:48, Yukihiro Matsumoto [e-mail] wrote:
| Hi,
|
| I have a few questions for the community.
|
| * If we have to pick one, which we should choose? Performance?
| Precision?
| * Is there any possibility to achieve both performance and precision
| at the same time? Or stolen_base has already fast enough? Without
| sacrificing precision? Any benchmark?
|
| matz.

I think the Date class need mainly performance, or - as another way to
say it - a better design.

Time's precision seems good enough, as the further example shows.
I am wondering of the utility of DateTime, so I will not speak about
its precision.

---

I have a question: What brings DateTime that Time does not have?

From tadayoshi funaba's example,

p 1000.times.inject(Time.new(2000)) {|s, | s + Rational(1, 259200/(24*3600))}.strftime('%F %T %20N')
"2000-01-01 00:05:33 33333333333333333333"

From methods view:

DateTime.instance_methods - Time.instance_methods
Mainly aliases, a notion of different calendars, next_* (prev_*) and
the #<< and #>> operators.
These operators (and prev/next) could of course be implemented for
Time (and I think they should).

Time.instance_methods - DateTime.instance_methods
A few useful conversions and #round.

They have 10 common methods (if we except the ones of Object)

[Time.instance_methods(false), DateTime.instance_methods(false)].map {|m| m-Object.instance_methods }.reduce(:&)
=> [:sec, :min, :hour, :zone, :strftime, :to_time, :to_date,
:to_datetime, :xmlschema, :iso8601]

So, unless I am missing something,
do we even need DateTime, for which reason ?

---

On 28 November 2010 06:17, Jeremy Evans [e-mail] wrote:
| I think one of the fundamental problems with the standard library is
that Date objects are stored as DateTimes at midnight UTC.
| I think Date objects are fundamentally distinct from DateTimes, and
that a Date object should store no time related data.
| The problem with Date objects storing time related data is shown in
my RubyConf presentation

I totally agree mixing the Date class with a notion of time is bad design.
That is the main reason I want to support home_run, for Date.
And because I want a real and efficient Date class, or none.

On 28 November 2010 12:50, Arturo Garcia [e-mail] wrote:
| I saw the presentation for home_run and I would give a no for its
| inclusion in core, mainly for two things:
| 1. Is a reimplementation in C (I think we have bad performance because of the
| approach to the problem).
|
| 2. It reimplements the following, which I don't think is right:
| * (Date.today - 0.5).class ==> Date
| ?I have doubts about how can i substract half from a day and get a Date, and
| what was the time anyway? and alike. A date is a point in a calendar, not a
| point in time (for me, at least).

I would take these as 2 arguments for home_run.

I do not understand your opinion about (1). If you think we have bad
performance, a reimplementation in C should be good news.

About adding/subtracting non-Integer from a Date, I think it does not
make sense.
If you plan to have partial days, then you are thinking to some notion of Time.

I think it should even raise an exception when adding a partial day to a Date.
If you have at first a Date, and want to add some time notion,
date.to_time + 0.5
seems an explicit and a good way.

Regards,
B.D.

=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:33446] [Ruby 1.9-Feature#4068] Replace current standard Date/DateTime library with home_run"
on Sun, 28 Nov 2010 17:43:42 +0900, tadayoshi funaba [e-mail] writes:

|i'll welcome you if you support stolen_base with me.
|however, i think we will need support of matz and akr who is the maintainer of Time firstly.

I'd back you up, once the consensus is made.

						matz.

=end

[akr (Akira Tanaka)]

=begin
2010/11/28 tadayoshi funaba [e-mail]:

Issue #4068 has been updated by tadayoshi funaba.

i'll welcome you if you support stolen_base with me.
however, i think we will need support of matz and akr who is the maintainer of Time firstly.

I don't understand your plan.

Do you mean that Date and DateTime will be builtin?

Tanaka Akira

=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:33445] [Ruby 1.9-Feature#4068] Replace current standard Date/DateTime library with home_run"
on Sun, 28 Nov 2010 17:35:28 +0900, tadayoshi funaba [e-mail] writes:

|> I am not sure if we need to guarantee granularity less than a nano
|> second. Do we?
|
|?? but, we already have

Availability of undocumented feature on the specific version of
specific implementation does not assure anything. If we specify
rational precision for time and datetime, that means we have to force
JRuby, Rubinius etc. to have it too. The point is how much precision
we need in real world programs. Akira's intention (Time should
represent bintime (2**-64 precision)) expressed in [ruby-core:33447]
is reasonable. Do you have any other opinion?

						matz.

=end

[akr (Akira Tanaka)]

=begin
2010/11/29 Yukihiro Matsumoto [e-mail]:

Availability of undocumented feature on the specific version of
specific implementation does not assure anything. If we specify

It is documented.

time.c:
2209: * sec may have fraction if it is a rational.
2469: * can be Integer, Float, Rational, or other Numeric.
3174: * time.to_r -> a_rational
3176: * Returns the value of time as a rational number of seconds
3258: * The result is possibly rational.

I described Time can use Rational internally at [ruby-dev:38191].

Tanaka Akira

=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:33458] Re: [Ruby 1.9-Feature#4068] Replace current standard Date/DateTime library with home_run"
on Mon, 29 Nov 2010 14:10:02 +0900, Tanaka Akira [e-mail] writes:

|> Availability of undocumented feature on the specific version of
|> specific implementation does not assure anything. If we specify
|
|It is documented.
|time.c:
|2209: * sec may have fraction if it is a rational.
|2469: * can be Integer, Float, Rational, or other Numeric.
|3174: * time.to_r -> a_rational
|3176: * Returns the value of time as a rational number of seconds
|3258: * The result is possibly rational.
|

I described Time can use Rational internally at [ruby-dev:38191].
Tanaka Akira

It was datetime I was talking about. In anyway, I don't want to force
other implementations to use rationals as internal representative,
neither for Time nor Date nor DateTime. Use of rationals should be
optional (among implementation) as an official specification.

						matz.

=end

[meta (mathew murphy)]

=begin
On Sat, Nov 27, 2010 at 19:28, tadayoshi funaba [e-mail]:

stolen_base will accept what all of Time represents thing except zonename
references and leapseconds.

Time zone abbreviations/names are ambiguous, so I'd vote in favor of not
supporting them at all.

POSIX doesn't support leap seconds; POSIX time is really TAI, but system
clocks are either discontinuous or sped up or slowed down in order to
approximate UTC. So I don't see lack of support for leap seconds as being a
deal-killer.

On Sat, Nov 27, 2010 at 23:17, Jeremy Evans [e-mail] wrote:

The reason for the difference in Tadayoshi's second example is because
home_run doesn't implement the undocumented strftime modifier options and
because it stores the timezone offset in minutes.

...and time zone offset being an exact number of minutes is another POSIX
limitation.

I have no problem with using stolen_base instead of home_run, at least for

DateTime. I think one of the fundamental problems with the standard library
is that Date objects are stored as DateTimes at midnight UTC. I think Date
objects are fundamentally distinct from DateTimes, and that a Date object
should store no time related data.

More precisely, I think that when people talk about a date, what they really
mean is that date, in whatever time zone the reader/viewer/user happens to
be in.

The period of time I refer to as 2010-11-29 is mostly 2010-11-30 in Japan,
but when we talk about something happening on 2010-11-29 we ignore this
subtlety. Nobody expects 2010-11-29 to become 2010-11-30 if viewed in a
different time zone. If for some reason they do need that, they can use
DateTime to get it.

So yes, I agree. Date objects should be their own thing, with no Time
component.

A more general approach is that taken by the JSR-310 proposed replacement
for Java's date and time APIs, which allows "partials"--incompletely
specified positions on the timeline. So not only can you have 2010-11-29,
you can have November 29 with no year specified.

On Sun, Nov 28, 2010 at 01:30, Yukihiro Matsumoto [e-mail]
wrote:

I am not sure if we need to guarantee granularity less than a nano
second. Do we?

POSIX seems to require microseconds, so nanosecond precision ought to be
more than enough I'd think. If people start using Ruby to control the Large
Hadron Collider they'll just have to write their own high precision
date/time library. :-)

On Sun, Nov 28, 2010 at 23:18, Yukihiro Matsumoto [e-mail]
wrote:

In anyway, I don't want to force
other implementations to use rationals as internal representative,
neither for Time nor Date nor DateTime. Use of rationals should be
optional (among implementation) as an official specification.

In that case, matching POSIX would be a good basis for the official spec,
yes? No rationals or reals, just integers.

mathew

URL:http://www.pobox.com/~meta/

On Sat, Nov 27, 2010 at 19:28, tadayoshi funaba <[e-mail]> wrote:

stolen_base will accept what all of Time represents thing except zonename references and leapseconds.

Time zone abbreviations/names are ambiguous, so I'd vote in favor of not supporting them at all.

POSIX doesn't support leap seconds; POSIX time is really TAI, but system clocks are either discontinuous or sped up or slowed down in order to approximate UTC. So I don't see lack of support for leap seconds as being a deal-killer.

On Sat, Nov 27, 2010 at 23:17, Jeremy Evans <[e-mail]> wrote:

The reason for the difference in Tadayoshi's second example is because home_run doesn't implement the undocumented strftime modifier options and because it stores the timezone offset in minutes.

...and time zone offset being an exact number of minutes is another POSIX limitation.

I have no problem with using stolen_base instead of home_run, at least for DateTime.  I think one of the fundamental problems with the standard library is that Date objects are stored as DateTimes at midnight UTC.  I think Date objects are fundamentally distinct from DateTimes, and that a Date object should store no time related data. 

More precisely, I think that when people talk about a date, what they really mean is that date, in whatever time zone the reader/viewer/user happens to be in.

The period of time I refer to as 2010-11-29 is mostly 2010-11-30 in Japan, but when we talk about something happening on 2010-11-29 we ignore this subtlety. Nobody expects 2010-11-29 to become 2010-11-30 if viewed in a different time zone. If for some reason they do need that, they can use DateTime to get it.

So yes, I agree. Date objects should be their own thing, with no Time component.

A more general approach is that taken by the JSR-310 proposed replacement for Java's date and time APIs, which allows "partials"--incompletely specified positions on the timeline. So not only can you have 2010-11-29, you can have November 29 with no year specified.

On Sun, Nov 28, 2010 at 01:30, Yukihiro Matsumoto <[e-mail]> wrote:

I am not sure if we need to guarantee granularity less than a nano

second.  Do we?

POSIX seems to require microseconds, so nanosecond precision ought to be more than enough I'd think. If people start using Ruby to control the Large Hadron Collider they'll just have to write their own high precision date/time library. :-)

On Sun, Nov 28, 2010 at 23:18, Yukihiro Matsumoto <[e-mail]> wrote:

In anyway, I don't want to force
other implementations to use rationals as internal representative,
neither for Time nor Date nor DateTime.  Use of rationals should be
optional (among implementation) as an official specification.

In that case, matching POSIX would be a good basis for the official spec, yes? No rationals or reals, just integers.

mathew
--
<URL:http://www.pobox.com/~meta/>

=end

=begin
I agree with Benoit and Mathew, that a date should be a point in a calendar, not in time (and reserve DateTime or Time for those cases). Furthermore, I think the partials (below), e.g. day and month without year or just a day, would be useful. E.g. when representing something that recur the 10th of every month.

"A more general approach is that taken by the JSR-310 proposed replacement
for Java's date and time APIs, which allows "partials"--incompletely
specified positions on the timeline. So not only can you have 2010-11-29,
you can have November 29 with no year specified."
=end

[tadf (tadayoshi funaba)]

=begin
matz,

in the first place, i don't want any restrictions if possible.

stolen_date does what Time does.
it is stolen_base's concept.

built-in Time exists outside of real world?

=end

[tadf (tadayoshi funaba)]

=begin
akr,

no.
it's not my aim.

=end

[tadf (tadayoshi funaba)]

=begin
in fact, unix cal(1) inspired the first yasuo version.

=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:33552] [Ruby 1.9-Feature#4068] Replace current standard Date/DateTime library with home_run"
on Sat, 4 Dec 2010 08:30:27 +0900, tadayoshi funaba [e-mail] writes:

|in the first place, i don't want any restrictions if possible.

Me too. But designing software is a sequence of trade-offs. I need
data to make the decision.

|built-in Time exists outside of real world?

I am not sure yet. I need more input.

						matz.

=end

[tadf (tadayoshi funaba)]

• File switch_hitter.patch switch_hitter.patch added
• File bm2.rb bm2.rb added

=begin
i've just written initial version of "switch_hitter".
i've attached the patch to trunk and a script.

swich_hitter provides both speed and quality.
swich_hitter has highly compatibility with the current date.

d = Date.new(2001,2,23) #=> #<Date::Light: 2001-02-23 (2451964)>
d + 1 #=> #<Date::Light: 2001-02-24 (2451965)>

d += Rational(3,2) #=> #<Date::Right: 2001-02-24 (2451965/1,0,2299161.0)>
d.ctime #=> "Sat Feb 24 12:00:00 2001"

d = Date.new(1582,10,15) #=> #<Date::Light: 1582-10-15 (2299161)>
d - 1 #=> #<Date::Right: 1582-10-04 (4598319/2,0,2299161.0)>

swich_hitter is fast only on purely small gregorian dates.
i didn't enough replace methods with c yet.
however, switch_hitter and home_run are even on some cases, i think.

switch_hitter:
user system total real
Date::valid_date?: 0.030000 0.000000 0.030000 ( 0.029646)
Date::new: 0.040000 0.000000 0.040000 ( 0.042592)
Date#to_s: 0.080000 0.000000 0.080000 ( 0.072524)
Date#+: 0.040000 0.000000 0.040000 ( 0.042738)
Date#-: 0.050000 0.000000 0.050000 ( 0.048020)
[Date]#sort: 0.220000 0.000000 0.220000 ( 0.224903)

home_run:
user system total real
Date::valid_date?: 0.030000 0.000000 0.030000 ( 0.022076)
Date::new: 0.040000 0.000000 0.040000 ( 0.048092)
Date#to_s: 0.100000 0.000000 0.100000 ( 0.093716)
Date#+: 0.030000 0.000000 0.030000 ( 0.034154)
Date#-: 0.040000 0.000000 0.040000 ( 0.033082)
[Date]#sort: 0.270000 0.000000 0.270000 ( 0.262382)

=end

[jeremyevans0 (Jeremy Evans)]

=begin
switch_hitter looks great. I still don't think the Date class should handle fractional dates, but it's true that doing so will increase compatibility with the current standard date library. I fully support switch_hitter replacing the current standard date library after it is ready. I think switch_hitter will get close to home_run's performance in most cases, since it takes a similar approach (DateLightData is home_run's data structure plus the sg field). I only recommend looking at home_run's Date#strftime, Date._strptime, and Date._parse implementations, since those are the methods unrelated to the core data structure that are very slow in the current standard date library and much faster in home_run.
=end

[akr (Akira Tanaka)]

=begin
2010/12/4 tadayoshi funaba [e-mail]:

no.
it's not my aim.

Why you want my support?
Will you modify time.c?

Tanaka Akira

=end

[tadf (tadayoshi funaba)]

=begin
akr,

stolen_base use internal functions of time.c.
i supposed it may affect your works.
however now i'm interested in switch_hitter rather than stolen_base.
it never use time's private functions.

thanks
=end

[tadf (tadayoshi funaba)]

=begin
if we can adopt switch_hitter's design, we may use home_run's implementation.
if so, i'd like the author of home_run to maintain it.
and anyway, i'd like to talk also about improvements of some format methods in the near future.

=end

[meta (mathew murphy)]

=begin
On Sat, Dec 4, 2010 at 01:28, Jeremy Evans [e-mail] wrote:

switch_hitter looks great. I still don't think the Date class should
handle fractional dates, but it's true that doing so will increase
compatibility with the current standard date library.

I don't think I even understand what fractional dates are. Does anyone
actually use them extensively? Are they part of the Japanese calendar or
something?

mathew
[ Serious question. ]

On Sat, Dec 4, 2010 at 01:28, Jeremy Evans <[e-mail]> wrote:

switch_hitter looks great.  I still don't think the Date class should handle fractional dates, but it's true that doing so will increase compatibility with the current standard date library.

I don't think I even understand what fractional dates are. Does anyone actually use them extensively? Are they part of the Japanese calendar or something?

mathew

[ Serious question. ]

=end

[jeremyevans0 (Jeremy Evans)]

=begin
mathew,

Fractional dates means that a Date object also holds a time component. They are an implementation detail of the current standard date library, which stores both Date and DateTime objects using the same data structure. It leads to the problem shown in http://jeremyevans-pres.heroku.com/rc2010_presentation/img40.html. Also, two Date objects that represent the same date can be considered non-equal because they have different times (e.g. one at midnight and one at noon).
=end

[tadf (tadayoshi funaba)]

=begin

t = Time.new(2001)
#=> 2001-01-01 00:00:00 +0900
t += 0.5
#=> 2001-01-01 00:00:00 +0900
t + 0.5
#=> 2001-01-01 00:00:01 +0900

same.
not problem.
and date objest shows the difference in inspect.

=end

[meta (mathew murphy)]

=begin
On Sat, Dec 4, 2010 at 13:31, Jeremy Evans [e-mail] wrote:

Fractional dates means that a Date object also holds a time component.
They are an implementation detail of the current standard date library,
which stores both Date and DateTime objects using the same data structure.
It leads to the problem shown in
http://jeremyevans-pres.heroku.com/rc2010_presentation/img40.html. Also,
two Date objects that represent the same date can be considered non-equal
because they have different times (e.g. one at midnight and one at noon).

Well, unless that behavior was ever documented as part of the API, I'd say
it's worth removing.

mathew

URL:http://www.pobox.com/~meta/

On Sat, Dec 4, 2010 at 13:31, Jeremy Evans <[e-mail]> wrote:

Fractional dates means that a Date object also holds a time component.  They are an implementation detail of the current standard date library, which stores both Date and DateTime objects using the same data structure. It leads to the problem shown in http://jeremyevans-pres.heroku.com/rc2010_presentation/img40.html.  Also, two Date objects that represent the same date can be considered non-equal because they have different times (e.g. one at midnight and one at noon).

Well, unless that behavior was ever documented as part of the API, I'd say it's worth removing.

 

mathew
--
<URL:http://www.pobox.com/~meta/>

=end

[tadf (tadayoshi funaba)]

• Status changed from Assigned to Rejected

=begin

=end