| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| | |
Use frozen-string-literal in ActiveSupport
|
| | |
|
|\ \
| |/
|/| |
Mention Time.zone.parse possibly throwing ArgumentError
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
| |
If a country doesn't exist in the MAPPINGS hash then create a new
`ActiveSupport::Timezone` instance using the supplied timezone id.
Fixes #28431.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously there was no way to get a RFC 3339 timestamp
into a specific timezone without either using `parse` or
chaining methods. The new method allows parsing directly
into the timezone, e.g:
>> Time.zone = "Hawaii"
=> "Hawaii"
>> Time.zone.rfc3339("1999-12-31T14:00:00Z")
=> Fri, 31 Dec 1999 14:00:00 HST -10:00
This new method has stricter semantics than the current
`parse` method and will raise an `ArgumentError`
instead of returning nil, e.g:
>> Time.zone = "Hawaii"
=> "Hawaii"
>> Time.zone.rfc3339("foobar")
ArgumentError: invalid date
>> Time.zone.parse("foobar")
=> nil
It will also raise an `ArgumentError` when either the
time or offset components are missing, e.g:
>> Time.zone = "Hawaii"
=> "Hawaii"
>> Time.zone.rfc3339("1999-12-31")
ArgumentError: invalid date
>> Time.zone.rfc3339("1999-12-31T14:00:00")
ArgumentError: invalid date
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously there was no way to get a ISO 8601 timestamp into a specific
timezone without either using `parse` or chaining methods. The new method
allows parsing directly into the timezone, e.g:
>> Time.zone = "Hawaii"
=> "Hawaii"
>> Time.zone.iso8601("1999-12-31T14:00:00Z")
=> Fri, 31 Dec 1999 14:00:00 HST -10:00
If the timestamp is a ISO 8601 date (YYYY-MM-DD) then the time is set
to midnight, e.g:
>> Time.zone = "Hawaii"
=> "Hawaii"
>> Time.zone.iso8601("1999-12-31")
=> Fri, 31 Dec 1999 00:00:00 HST -10:00
This new method has stricter semantics than the current `parse` method
and will raise an `ArgumentError` instead of returning nil, e.g:
>> Time.zone = "Hawaii"
=> "Hawaii"
>> Time.zone.iso8601("foobar")
ArgumentError: invalid date
>> Time.zone.parse("foobar")
=> nil
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
9.0.0 was released on June 21, 2016
http://blog.unicode.org/2016/06/announcing-unicode-standard-version-90.html
http://www.unicode.org/versions/Unicode9.0.0/
There are some changes about grapheme cluster in Unicode 9.0.0:
http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundary_Rules
------------
I noticed that `unpack_graphemes` returns [Other] when the argument is Other ÷ Prepend
(it must be [Other, Prepend]).
But in [Unicode 8.0.0's Prepend has no characters](http://www.unicode.org/reports/tr29/tr29-27.html#Prepend)
so we don't have to backport following patch:
```diff
should_break =
+ if pos == eoc
+ true
```
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This can be an issue when TZInfo::TimeZone#current_period is refreshed
due to timezone period transition, but it's not reflected in
ActiveSupport::TimeZone object.
For example, on Sun, 26 Oct 2014 22:00 UTC, Moscow changed its TZ from
MSK +04:00 to MSK +03:00 (-1 hour). If ActiveSupport::TimeZone['Moscow']
happens to be initialized just before the timezone transition, it will
cache its stale utc_offset even after the timezone transition.
This commit removes cache and fixes this issue.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
|
|
|
|
|
|
| |
That helper will return time zones for any country that tzdata knows about.
So it will be much simpler for non-US people to list own country time zones
in HTML selects or anywhere.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The bundled version of TZInfo referred to was removed from Active
Support in version 3.0.
|
|\ |
|
| | |
|
| |
| |
| | |
Output of `formatted_offset` is depends on input so it’s not always in +HH:MM format. Possible outputs are “+5:30”, “+530” or provided alternate UTC string [ci skip]
|
|/
|
|
|
|
|
| |
The thread_safe gem is being deprecated and all its code has been merged
into the concurrent-ruby gem. The new class, Concurrent::Map, is exactly
the same as its predecessor except for fixes to two bugs discovered
during the merge.
|
|
|
|
|
| |
`TimeZone` class is a part of `ActiveSupport` module. For Accessing `TimeZone` class, we need to call `ActiveSupport::TimeZone` instead of `TimeZone`.
individual `TimeZone` gives `NameError: uninitialized constant ‘TimeZone’ error
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously when converting AS::TimeWithZone to YAML it would be output
as a UTC timestamp. Whilst this preserves the time information accurately
it loses the timezone information. This commit changes that so that it is
saved along with the time information. It also provides nicer encoding of
AS::TimeZone instances themselves which previously embedded all of the
data from the TZInfo records.
Fixes #9183.
|
|
|
|
|
| |
Make strptime behave more like parse when components are missing and
share behavior between the two methods.
|
|
|
|
| |
This makes it easier to parse user-inputted times as from a given time zone.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reverting this as it's not the implementation that we would like it to be.
This is being used inside of ActiveSUpport::TimeZone[] and it's unaware
of the context in which to find the timezone period so the timezone found
changes depending on whether DST is in effect for the current period.
This means that `'2001-01-01'.in_time_zone(-9)` changes from winter/summer
even though it's the same date that we're trying to convert.
Since finding timezones by numeric offsets is a bit hit and miss we should
introduce a new API for finding them which supplies the date context in
which we want to search and we should probably also deprecate the finding
of timezones via the [] method, though this needs further discussion.
This reverts commit 2cc2fa3633edd96773023c6b09d07c7b9d9b841d.
|
|
|
|
|
|
| |
When given a specific offset, use the first result found where the
total current offset (including any periodic deviations such as DST)
from UTC is equal.
|
|
|
|
|
| |
Conflicts:
activesupport/lib/active_support/values/time_zone.rb
|
|
|
|
| |
Also sync Russian Federation time zones with `zone.tab` file from tzdata version 2014j.
|
|
|
|
|
| |
Since real timezone is loaded anyway in `#utc_offset`
which is called during `#create`
|
| |
|
|
|
|
|
|
|
|
| |
7.0.0 was released on June 16, 2014
http://unicode-inc.blogspot.com.ar/2014/10/unicode-version-70-complete-text-of.html
ruby bin/generate_tables
|
| |
|
|
|
|
|
|
| |
`try` allocates an array on every call, we should avoid calling it in
hotspots. This reduced AttributeMethodsTest#test_setting_time_zone_aware_attribute_with_string
from 18k allocations to 14k
|
|
|
|
| |
Just moved class methods up in file and moved `def self.` methods into `class << self`.
|
| |
|
|
|
|
|
| |
Namely, if the mday is omitted but any other upper components are, then instead
of supplying the mday from the current time, it defaults to 1.
|
|
|
|
|
|
| |
Apparently we've been using a buggy feature for the past 6 years:
https://bugs.ruby-lang.org/issues/9593
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently if a time is changed during DST overlap in the autumn then the
method `period_for_local` will return the DST period. However if the
original time is not DST then this can be surprising and is not what is
generally wanted. This commit changes that behavior to maintain the current
period if it's in the list of periods returned by `periods_for_local`.
It is possible to alter the behavior of `period_for_local` by specifying a
second argument but since we may be change from another time that could be
either DST or not then this would give inconsistent results.
Fixes #12163.
|
|
|
|
| |
https://github.com/ruby/ruby/commit/d781caaf313b8649948c107bba277e5ad7307314
|
|
|
|
|
|
|
|
|
| |
Lazy loading the tzinfo library doesn't really buy us anything because
the gem is installed as a dependency via the gemspec and if a developer
is using Active Support outside of Rails then they can cherry pick which
files to load anyway.
Fixes #13553
|