[ruby-core:33477] Re: [Ruby 1.9-Feature#4068] Replace current standard Date/DateTime library with home_run

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/>