| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
For parity with Ruby's Time::at
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this change missing timezone data for any of the time zones
defined in `ActiveSupport::Timezone::MAPPING` caused a `comparison of
NilClass with ActiveSupport::TimeZone failed` exception.
Attempting to get a timezone by passing a number/duration to `[]` or
calling `all` directly will try to sort sort the values of `zones_map`.
Those values are initialized by the return value of `create(zonename)`
which returns `nil` if `TZInfo` is unable to find the timezone
information.
In our case the exception was triggered by an outdated tzdata package
which did not include information for the "recently" added time zones.
Before 078421bacba178eac6a8e607b16f3f4511c5d72f `zones_map` only
returned the information that have been loaded into `@lazy_zone_map`
which ignored time zones for which the data could not be loaded, this
change restores the previous behaviour.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some timezones like `Europe/London` have multiple mappings in
`ActiveSupport::TimeZone::MAPPING` so return all of them instead
of the first one found by using `Hash#value`. e.g:
# Before
ActiveSupport::TimeZone.country_zones("GB") # => ["Edinburgh"]
# After
ActiveSupport::TimeZone.country_zones("GB") # => ["Edinburgh", "London"]
Fixes #31668.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make `ActiveSupport::TimeWithZone` match Ruby's handling of ambiguous
times by choosing the later period, e.g.
Ruby:
```
ENV["TZ"] = "Europe/Moscow"
Time.local(2014, 10, 26, 1, 0, 0) # => 2014-10-26 01:00:00 +0300
```
Before:
```
>> "2014-10-26 01:00:00".in_time_zone("Moscow")
TZInfo::AmbiguousTime: 26/10/2014 01:00 is an ambiguous local time.
```
After:
```
>> "2014-10-26 01:00:00".in_time_zone("Moscow")
=> Sun, 26 Oct 2014 01:00:00 MSK +03:00
```
Fixes #17395.
|
|
|
|
| |
Reverts 7abb6e0.
|
| |
|
|\
| |
| | |
Use frozen-string-literal in ActiveSupport
|
| | |
|
| |
| |
| |
| |
| | |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| | |
|
|/ |
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
assert [1, 3].includes?(2) fails with unhelpful "Asserting failed" message
assert_includes [1, 3], 2 fails with "Expected [1, 3] to include 2" which makes it easier to debug and more obvious what went wrong
|
|
|
|
|
| |
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.
|
|
|
|
| |
See 2f26f611 for more info.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Conflicts:
activesupport/lib/active_support/values/time_zone.rb
|
|
|
|
|
| |
Since real timezone is loaded anyway in `#utc_offset`
which is called during `#create`
|
|
|
|
|
|
| |
Hash#keys.each allocates an array of keys; Hash#each_key iterates through the
keys without allocating a new array. This is the reason why Hash#each_key
exists.
|
|
|
|
|
| |
It’s used at so many places that extracting it out into a helper file
is worth doing.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rails applications are expected to be always aware of the application
time zone.
To be consistent with that contract, we have to assume that a bare
date passed to time helpers is a date in the application time zone,
not in the system time zone. The system time zone is irrelevant, we
should totally ignore it.
For example,
travel_to user.birth_date + 40.years
should make that user be 40th years old regardless of the system
time zone. Without this patch that may not be true.
|
|
|
|
|
|
| |
This behavior is only work out-of-box with minitest and also add a
downside to run after each test case, even if we don't used the travel
or travel_to methods
|
|
|
|
|
|
|
| |
Ruby's Date class automatically gives us #yesterday, #today,
and #tomorrow. And ActiveSupport has a handy Time.zone.today
for getting a localized version. But there was no localized
version of #yesterday or #tomorrow. Until now.
|
| |
|
|
|
|
|
| |
The bug with `ActiveSupport::TimeZone.parse` described in #9678 was
unwittingly fixed in 005d910 so add some tests to prevent regression.
|
|
|
|
|
|
|
| |
When there are missing components in the Hash returned by
Date._parse only the date components should default to the
value of Time.zone.now, the time components should all
default to zero.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Chrome, Safari and Firefox serialize Date objects to strings such
as 'Mon May 28 2012 00:00:00 GMT-0700 (PDT)'. When these strings
are parsed the zone is interpreted as 'GMT-0700' which doesn't
exist in the TzInfo list of timezones.
By taking advantage of the improved date/time handling in 1.9.3
we can use `Date._parse` and the `:offset` value which is parsed
correctly.
Three tests were amended to make them pass:
1. test_parse_with_old_date
This needed changing to a different value because the original
value was before EST was adopted so was being changed to a
LMT (Local Mean Time) value after the change. It didn't before
because `DateTime` just has offsets from UTC not timezones.
2. test_parse_should_not_black_out_system_timezone_dst_jump
Changed the implementation of this test as the stubs were
dependent on internal implementation details of the test.
Confirmed that the modified test still failed when the
implementation of `parse` was restored to pre-#5571.
3. test_parse_should_black_out_app_timezone_dst_jump
Ditto.
Closes #5770.
|
|
|
|
| |
format strings.
|
|
|
|
|
|
|
|
| |
differs from that.
The system timezone DST jump hour should not be blacked out by Time.zone.parse if current Time.zone does not do the jump at that time.
Fixes #5559.
|
| |
|
| |
|
| |
|