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 fav= or of not supporting them at all.

POSIX doesn't support leap seconds; POSIX time is r= eally 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 le= ap seconds as being a deal-killer.

On Sat, Nov 27, 2010 at 23:17, = Jeremy Evans=A0<redmine@ruby-lang.org>=A0wrote:

The reason for the difference in Tadayoshi's second example is because = home_run doesn't implement the undocumented strftime modifier options a= nd 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. =A0I think one of the fundamental problem= s with the standard library is that Date objects are stored as DateTimes at= midnight UTC. =A0I think Date objects are fundamentally distinct from Date= Times, and that a Date object should store no time related data.=A0

More precisely, I think that when people talk about a d= ate, what they really mean is that date, in whatever time zone the reader/v= iewer/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 abou= t 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 t= ime APIs, which allows "partials"--incompletely specified positio= ns on the timeline. So not only can you have 2010-11-29, you can have Novem= ber 29 with no year specified.

On Sun, Nov 28, 2010 at 01:30, = Yukihiro Matsumoto=A0<matz@ruby-lang.org>=A0wrote:

I am not sure if we need to guarantee granularity less th= an a nano
second. =A0Do we?

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

On Sun, Nov 28, 2010 at 23:18, = Yukihiro Matsumoto=A0<matz@ruby-lang.org>=A0wrote:
In anyway, I don't want to force
other implementations to use ration= als as internal representative,
neither for Time nor Date nor DateTime. = =A0Use of rationals should be
optional (among implementation) as an offi= cial specification.

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

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