When assigning a hash to a time attribute that's missing a year
component (e.g. a `time_select` with `:ignore_date` set to `true`)
then the year defaults to 1970 instead of the expected 2000. This
results in the attribute changing as a result of the save.

Before:

    event = Event.new(start_time: { 4 => 20, 5 => 30 })
    event.start_time # => 1970-01-01 20:30:00 UTC
    event.save
    event.reload
    event.start_time # => 2000-01-01 20:30:00 UTC

After:

    event = Event.new(start_time: { 4 => 20, 5 => 30 })
    event.start_time # => 2000-01-01 20:30:00 UTC
    event.save
    event.reload
    event.start_time # => 2000-01-01 20:30:00 UTC

Related 34cc301f.

`QueryAttribute#value_for_database` calls only `type.serialize`, and
`Decimal#serialize` is a no-op unlike other attribute types.

Whether or not `serialize` will invoke `cast` is undefined in our test
cases, but it actually does not work properly unless it does so for now.

Since Rails 6.0 will support Ruby 2.4.1 or higher
`# frozen_string_literal: true` magic comment is enough to make string object frozen.
This magic comment is enabled by `Style/FrozenStringLiteralComment` cop.

* Exclude these files not to auto correct false positive `Regexp#freeze`
 - 'actionpack/lib/action_dispatch/journey/router/utils.rb'
 - 'activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb'

It has been fixed by https://github.com/rubocop-hq/rubocop/pull/6333
Once the newer version of RuboCop released and available at Code Climate these exclude entries should be removed.

* Replace `String#freeze` with `String#-@` manually if explicit frozen string objects are required

 - 'actionpack/test/controller/test_case_test.rb'
 - 'activemodel/test/cases/type/string_test.rb'
 - 'activesupport/lib/active_support/core_ext/string/strip.rb'
 - 'activesupport/test/core_ext/string_ext_test.rb'
 - 'railties/test/generators/actions_test.rb'

For example, dirty checking was not right for the following case:

```
model.int_column = "+5"
model.float_column = "0.5E+1"
model.decimal_column = "0.5e-3"
```

It is enough to see whether leading character is a digit for avoiding
invalid numeric expression like 'wibble' to be type-casted to 0, as
this method's comment says.

Fixes #33801

The multiplication of the value takes a long time when we can instead mutate and use the string value directly.

The `microsec` perf increases speed by 27% in the ideal case (which is the most common).

```
original_string = ".443959"

require 'benchmark/ips'

Benchmark.ips do |x|
  x.report("multiply") { 
    string = original_string.dup
    (string.to_r * 1_000_000).to_i 
  }
  x.report("new     ") { 
    string = original_string.dup
    if string && string.start_with?(".".freeze) && string.length == 7
      string[0] = ''.freeze
      string.to_i
    end
  }
  x.compare!
end

# Warming up --------------------------------------
#             multiply   125.783k i/100ms
#             new        146.543k i/100ms
# Calculating -------------------------------------
#             multiply      1.751M (± 3.3%) i/s -      8.805M in   5.033779s
#             new           2.225M (± 2.1%) i/s -     11.137M in   5.007110s

# Comparison:
#             new     :  2225289.7 i/s
#             multiply:  1751254.2 i/s - 1.27x  slower
```

`QueryAttribute#value_for_database` calls only `type.serialize`, and
`Boolean#serialize` is a no-op unlike other attribute types.

It caused the issue #32624. Whether or not `serialize` will invoke
`cast` is undefined in our test cases, but it actually does not work
properly unless it does so for now.

Fixes #32624.

Since #26074, introduced force equality checking to build a predicate
consistently for both `find` and `create` (fixes #27313).

But the assumption that only array/range attribute have subtype was
wrong. We need to make force equality checking more strictly not to
allow serialized attribute.

Fixes #32761.

Before it was coercing an invalid string into "2000-01-01 00:00:00".

Inside user_input_in_time_zone we call in_time_zone on the value and value can be a String.

For legacy reasons Rails stores time columns on sqlite as full
timestamp strings. However because the date component wasn't being
normalized this meant that when they were read back they were being
prefixed with 2001-01-01 by ActiveModel::Type::Time. This had a
twofold result - first it meant that the fast code path wasn't being
used because the string was invalid and second it was corrupting the
second fractional component being read by the Date._parse code path.

Fix this by a combination of normalizing the timestamps on writing
and also changing Active Model to be more lenient when detecting
whether a string starts with a date component before creating the
dummy time value for parsing.

In #20317, datetime columns had their precision applied on assignment but
that behaviour wasn't applied to time columns - this commit fixes that.

Fixes #30301.

https://bugs.ruby-lang.org/issues/12752
https://ruby-doc.org/core-2.4.0/String.html#method-i-unpack1

BC dates are supported by both date and datetime types.

https://www.postgresql.org/docs/current/static/datatype-datetime.html

Since #1097, new datetime allows year zero as 1 BC, but new date does
not. It should be allowed even in new date consistently.

This basically reverts ee5cfc01

Between 4.2 and 5.0 the behavior of how multiparameter attributes
interact with `_before_type_cast` changed. In 4.2 it returns the
post-type-cast value. After 5.0, it returns the hash that gets sent to
the type. This behavior is correct, but will cause an issue if you then
tried to render that value in an input like `text_field` or
`hidden_field`.

In this case, we want those fields to use the post-type-cast form,
instead of the `_before_type_cast` (the main reason it uses
`_before_type_cast` at all is to avoid losing data when casting a
non-numeric string to integer).

I've opted to modify `came_from_user?` rather than introduce a new
method for this as I want to avoid complicating that contract further,
and technically the multiparameter hash didn't come from assignment, it
was constructed internally by AR.

Close #27888.

`ActiveModel::Type::DateTime#serialize` should return a `Time` object
so that finding by a datetime column works correctly.

This reverts commit 3420a145, reversing
changes made to afb66a5a.

See 34321e4a for background on
ImmutableString vs String.

Our String type cannot delegate typecasting to ImmutableString, because
the latter freezes its input: duplicating the value after that gives us
an unfrozen result, but still mutates the originally passed object.

In Ruby 2.4, BigDecimal(), as used by the Decimal cast, was changed so
that it will raise ArgumentError when passed an invalid string, in order
to be more consistent with Integer(), Float(), etc. The other numeric
types use ex. to_i and to_f.

Unfortunately, we can't simply change BigDecimal() to to_d. String#to_d
raises errors like BigDecimal(), unlike all the other to_* methods (this
should probably be filed as a ruby bug).

Instead, this simulates the existing behaviour and the behaviour of the
other to_* methods by finding a numeric string at the start of the
passed in value, and parsing that using BigDecimal().

See also
https://bugs.ruby-lang.org/issues/10286
https://github.com/ruby/bigdecimal/commit/3081a627cebdc1fc119425c7a9f009dbb6bec8e8

Right now it behaves differently on JRuby:

```
--- expected
+++ actual
@@ -1 +1 @@
-#<BigDecimal:5f3c866c,'0.333333333333333333',18(20)>
+#<BigDecimal:16e0afab,'0.3333333333333333',16(20)>
```

My initial PR (https://github.com/rails/rails/pull/27324)
offered to let the precision to be decided by the platform and
change the test expection, but other contributors suggested
that we should change the default precision in Rails
to be consistent of all platforms.

The value (18) comes from the max default precision that comes
from casting Rational(1/3) to BigDecimal.

As pointed out by @matthewd this change makes ImmutableString aware
of MysqlString's existence whereas previously MysqlString was only
overriding public API.

cc @kamipo

This reverts commit e632c2fa, reversing
changes made to 334a7dcf.

The only difference between `Type::ImmutableString` and its subclasses
is the representation of the casted booleans. Prefer extracting
`casted_true`/`casted_false` and override these by subclasses.

Currently dumping defaults on schema is inconsistent.

Before:

```ruby
  create_table "defaults", force: :cascade do |t|
    t.string   "string_with_default",   default: "Hello!"
    t.date     "date_with_default",     default: '2014-06-05'
    t.datetime "datetime_with_default", default: '2014-06-05 07:17:04'
    t.time     "time_with_default",     default: '2000-01-01 07:17:04'
    t.decimal  "decimal_with_default",  default: 1234567890
  end
```

After:

```ruby
  create_table "defaults", force: :cascade do |t|
    t.string   "string_with_default",   default: "Hello!"
    t.date     "date_with_default",     default: "2014-06-05"
    t.datetime "datetime_with_default", default: "2014-06-05 07:17:04"
    t.time     "time_with_default",     default: "2000-01-01 07:17:04"
    t.decimal  "decimal_with_default",  default: "1234567890"
  end
```

Currently `apply_seconds_precision` cannnot round usec
when after `require 'mathn'`.

```
irb(main):001:0> 1234 / 1000 * 1000
=> 1000
irb(main):002:0> 1234 - 1234 % 1000
=> 1000
irb(main):003:0> require 'mathn'
=> true
irb(main):004:0> 1234 / 1000 * 1000
=> 1234
irb(main):005:0> 1234 - 1234 % 1000
=> 1000
```

ie. DecimalWithoutScale, Text and UnsignedInteger

All indentation was normalized by rubocop auto-correct at 80e66cc4.
But comments was still kept absolute position. This commit aligns
comments with method definitions for consistency.

Recently, the Rails team made an effort to keep the source code consistent, using Ruboco
(bb1ecdcc and below). Some of the case
statements were missed.

This changes the case statements' formatting and is consistent with changes
in 810dff7c and db63406c.