Especially over the year 2038, 30 Feb and so on may cause odd behavior
on validating found epoch with given year-month-day [Bug #15340]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65974 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* time.c (tm_initialize): allow 7th argument as well as
Time#initialize, but just ignore.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65420 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* time.c (time_localtime): check if `vtm.zone` is a simple zone
name string before trying to call the conversion method. since
r64952, `Time.getlocal` on UTC time has lost the performance
about 45%, due to this call. the performance is about 90% of
r64951 by avoiding it.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65360 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* time.c (tm_initialize): arguments other than year are optional
now as Time.new.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65296 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The former states explicitly that the argument must be a literal,
and can optimize away `strlen` on all compilers.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65059 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* time.c (zone_str): while rb_fstring_usascii and the family
require that the argument string is never modified, tzname may
point areas which will be discarded by calling tzset().
make a String then call rb_fstring to copy the zone name.
when an ID equals TZ environment variable, its name string also
has modified by changing tzname.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65035 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* time.c (time_utc_or_local): split into time_s_mkutc and
time_s_mktime without utc flag.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64700 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* time.c (rb_localtime_r): call tzset() only after TZ environment
variable is changed.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63994 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* Both timegmw and gmtimew ignores leap second if the timezone doesn't
have leap seconds on the first call of init_leap_second_info()
* Add Bug::Time.reset_leap_second_info for testing
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63857 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Time.utc uses timegmw() and it uses leap second information.
If the given time is larger than known_leap_seconds_limit, it calls
find_time_t, which uses localtime(3) and calls stat(2) in it.
This patch avoid it by setting known_leap_seconds_limit to 0 if the timezone doesn't have leapsecond information (if no leap second is found "now", I assume the timezone doesn't have leapsecond information).
Before:
% time ./miniruby --disable-gem -e'time = Time.now; year = time.year; month = time.month; day = time.day; hour = time.hour; min = time.min; sec = time.sec + time.subsec; i = 0; while i < 100000; ::Time.utc(year, month, day, hour, min, sec); i += 1; end'
./miniruby --disable-gem 0.35s user 0.19s system 99% cpu 0.542 total
After:
% time ./miniruby --disable-gem -e'time = Time.now; year = time.year; month = time.month; day = time.day; hour = time.hour; min = time.min; sec = time.sec + time.subsec; i = 0; while i < 100000; ::Time.utc(year, month, day, hour, min, sec); i += 1; end'
./miniruby --disable-gem 0.23s user 0.00s system 99% cpu 0.233 total
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63848 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* time.c: state that Time#localtime does nothing when nothing
changes. [ruby-core:87675] [Bug #14880]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63823 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
No need to waste space on "to_r" and "to_int" which are
predefined in defs/id.def
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62006 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
compat_common_month_table and compat_leap_month_table should
not be writable.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62005 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
To be precise C90 says "A bit-field may have type int, unsigned
int, or signed int". It is clear that char or enum are NG.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61554 b2dd03c8-39d4-4d8f-98ff-823fe69b080e