I have a problem with timezone "Santiago". Chile changed to daylight time (GMT -3) from 1st september.
Time.now.in_time_zone("Santiago")
=> Tue, 04 Sep 2012 10:57:43 CLT -04:00 <<-- wrong, should be 11:57:43 CLT -03:00
Any idea?
Thanks.
Timezone data is provided by the tzdata gem. Rails requires a rather up to date version (iirc at least 0.3.31 for Rails 3.2.8), but as time zone definitions are rather short lived, sometimes you need to update them manually. In your case, you need at least 0.3.32 which includes the changes of the Chile DST. At the time of writing of this answer, the current version of tzdata is 0.3.33.
To force a newer version of tzdata, just add this to your Gemfile:
gem 'tzdata', '~> 0.3.33'
Related
I went to GitHub issues to raise a support ticket but thought of asking the question first to avoid noise.
This is what the docs says-
Omit the version completely or use "latest" to load the latest one (not recommended for production usage):
/npm/jquery#latest/dist/jquery.min.js
/npm/jquery/dist/jquery.min.js
According to the doc, either we can latest or omit it completely to load the latest version. But I'm seeing a difference-
With latest added (URL 1 - U1)
Example- https://cdn.jsdelivr.net/npm/#letscooee/web-sdk#latest/dist/sdk.min.js
It loads the last released version that is cached for 24 hours. That means if we release v2 & v3 within 24 hours, the above URL will still show v1.
The caching period is 1 week.
Without latest (URL 2 - U2)
Example- https://cdn.jsdelivr.net/npm/#letscooee/web-sdk/dist/sdk.min.js
While we omit the latest completely, this loads the latest release immediately i.e. v3 and the caching period is also 1 week.
I have requested for the purge API as per their docs but I believe this behaviour is not aligning with their docs.
Tried to Google the cause and read their docs 3 times. Am I missing something?
Edit 1
After reading Martin's answer, I did the following-
(To view the images, open them in new tab & remove t before .png)
Step Taken
# Time
U1
U2
Purge Cache
12:39:00 UTC
Purged
Purged
See Age Header
# 12:40 UTC
0
0
See Date Header
# 12:40 UTC
Sun, 12 Sep 2021 12:40:25 GMT
Sun, 12 Sep 2021 12:40:31 GMT
Headers
12:41:00 UTC
Result
12:41:00 UTC
Points to latest release 0.0.3
Points to latest release 0.0.3
Publish new NPM release 0.0.4
12:48:00 UTC
Refresh both the URLs
12:49:00 UTC
Shows old release 0.0.3
Shows latest release 0.0.4
The last step shows that I was wrong here. This is working as expected (i.e. showing 0.0.3 only) as per the docs
The caching time is the same in both cases - 12 hours at the CDN level and 7 days in the browser: cache-control: public, max-age=604800, s-maxage=43200
That doesn't necessarily mean both URLs will always return the same content because both the CDN and your browser calculate the expiration for each URL independently, based on when it was first retrieved, so the CDN may serve different versions for up to 12 hours after the release.
Seems to me both the links point to the same sdk URL.
As per how cdns work would be to mention the version of the sdk for example:
<script src="https://unpkg.com/three#0.126.0/examples/js/loaders/GLTFLoader.js"></script>
or as per below which will always point to the latest version of the sdk:
<script src="https://cdn.rawgit.com/mrdoob/three.js/master/examples/js/loaders/GLTFLoader.js"></script>
I already set celery4.4 config timezone is "Asia/Shanghai"
CELERY_TIMEZONE = "Asia/Shanghai"
And the terminal show now datetime.
2021-08-20 23:26:03,849
But the backend I use redis date_zone is not the same as the datetime now.
"date_done": "2021-08-20T15:26:03.848352"
I dont know where my config is wrong.
Currently as documented, the resulting date_done isn't based on the configured Celery timezone but rather is just always UTC. That is why you are seeing 15:26 (UTC) instead of 23:26 (UTC+8).
https://docs.celeryproject.org/en/stable/reference/celery.result.html#celery.result.AsyncResult.date_done
https://docs.celeryproject.org/en/stable/internals/reference/celery.backends.database.models.html
property date_done
UTC date and time.
This feature has already been requested before but seems to be always de-prioritized and moved for next release. Currently, it is planned to be included in Celery 5.2.
The celery result column, date_done is utc, even though you set the timezone
I have an application running on Heroku Bamboo and I need to migrate it to Cedar, but I have a problem with dates, because of my default_timezone:
# config/application.rb
config.time_zone = "Brasilia"
config.active_record.default_timezone = :local
With this configuration AR saves the date fields using PST (which is the :local value for Bamboo).
But it doesn't save the TZ info in the date fields, it only offsets the dates to PST, for example the values on PG are like 2015-01-26 17:20:00 with no TZ info.
After the Cedar migration and because of :local, AR assumes that 2015-01-26 17:20:00 is in UTC, causing wrong date values.
If I set heroku config:set TZ=America/Los_Angeles and use my_date_field.in_time_zone for all my date fields in the interface, it works on Cedar, but I doesn't feel that right.
Any ideas on other ways to fix that?
Problem solved
After setting ruby 1.9.2 on Cedar (default is 2.0) and with TZ set to America/Los_Angeles it worked in the same way it was working on Bamboo without requiring .in_time_zone.
Although I still don't know why 2.0 requires .in_time_zone to return the time using the TZ configured with config.time_zone.
Does anyone here knows how to solve the Tibco xpath daylight saving date issue.
The issue was we have one record 03/10/2013 02:00 parsed via Tibco mapping palette with following format (mm/dd/yyyy hh:mm). However, it got invalid date time error with above date. It worked with all other times, e.g. 03/10/2013 01:00, 03/10/2013 03:00, just not working with anytime between 03/10/2013 02:00 ~ 03/10/2013 02:59.
The current xpath we using parse-dateTime(format, string)
So, can xpath detect the daylight saving automatically with the inbound date format (mm/dd/yyyy hh:mm) and parse it?
Thanks so much.
James
Yes. The TIBCO function that parses dateTime does detect Day Light Saving.
I think you have two options to handle these cases in your engine.
Change the code to have a Java Code parse the dateTime. I am aware
that java correctly returns the time with 1 hour added in this case.
You should be able to do a TimeZone.getDefault() to get the server's
default TimeZone.
Change the java default timezone in the TRA - java.property.user.timezone in the designer.tra I suppose.
I have not tried these. :-)
I had the same problem with DST, trying to parse string 2014-03-30 02:00:00 which does not exist in italian timeZone.
Since the input date was perfectly legit (intended to be in GMT+0) I solved by forcing the timezone with this code. It should work with any other timezone as long as it doesn't support DST.
tib:parse-dateTime("yyyy-MM-dd HH:mm:ss Z"), concat($Start/root/dateTimeFrom, ' +0000')
Enable daylight in deployment.yaml (kubernetes)
- name: BW_JAVA_OPTS
value: "-Dbw.engine.enable.memory.saving.mode=true -Xms1024m -Xmx4096m"
I beat my head against this for a day and a half before it finally all came together, partly because I was fundamentally misunderstanding some things because of my assumptions of how things should work, and so the results I was getting seemed so completely irrational and confusing that I was starting to think things must be horribly broken in the libraries. They weren't.
This thread is to share my question, and what worked, partly because it seems to me that a lot of times a datetime record should be tied to the localtime of its location, and a lot of times when applications behave strangely with respect to timezone changes I think it's because they don't do that. So here's how to do that.
The easy part was using the TimeZone gem to get the location's timezone (I already have the latitude/longitude from using the GMaps4Rails gem), as described here: Ruby gem for finding timezone of location
Initially, I hoped each datetime could have an intrinsic and persistent time zone, even after being saved and retrieved from the DB, since we only care about the local time zone for each event. For the unusual and rare case where the datetime was needed in other-than-local-zone, I could convert. But I guess that doesn't exist since MySQL seem to have no concept of timezone with its datetime, and just stores everything as a plain ol' date and time.
So, that's fine -- the DB stores in UTC and I must do the conversions each direction.
How? (See below.)
User enters a datetime (year, month, day, hour, min, sec) in the appropriate local time for the event location. To save this as the correct UTC time in your DB, and retrieve later retrieve it and use it with its correct timezone, here's the recipe:
You must first set Time.zone = timezone -- where timezone is a named timezone string, like "America/Toronto" (GeoKit/TimeZone style) or "Eastern Time (US & Canada)" (Rails 3 style):
1.9.3p200 :001 > Time.zone = "America/Toronto"
=> "America/Toronto"
Note that it is nontrivial to map between the GeoKit/TimeZone style and the Rails 3 style. There is some support for that, but many of the mappings that GeoKit returns are not in the Rails mappings, so I'm sticking with the GeoKit/TimeZone names because they seem to work just fine, and I don't need user-selectable timezones because I'm taking care of all of that automagically for the user using the locations.
Now you can parse and save your datetime variable using ActiveSupport::TimeWithZone, and it will be encoded properly using the Time.zone parameter:
1.9.3p200 :002 > t = Time.zone.local( 2012, 8, 1, 12, 0, 0 )
=> Wed, 01 Aug 2012 12:00:00 EDT -04:00
i.e. In my case, for my Event model with instance event:
event.start = Time.zone.local( year, month, day, hour, min, sec )
event.save
When the data is saved to the DB, it is in UTC: 2012-08-01 16:00:00.000000
(Simulated below with call to t.utc)
1.9.3p200 :003 > t = t.utc
=> 2012-08-01 16:00:00 UTC
1.9.3p200 :004 > t.zone
=> "UTC"
Now, when you read it back from the DB, you need to again use the TimeWithZone support to tell the DateTime what timezone it is in.
Note that the in_time_zone function does not change the underlying datetime variable's timezone:
1.9.3p200 :005 > t.in_time_zone( "America/Toronto" )
=> Wed, 01 Aug 2012 12:00:00 EDT -04:00
1.9.3p200 :006 > t
=> 2012-08-01 16:00:00 UTC
1.9.3p200 :007 > t.zone
=> "UTC"
so you really need to assign the function output back to your datetime variable:
1.9.3p200 :008 > t = t.in_time_zone( "America/Toronto" )
=> Wed, 01 Aug 2012 12:00:00 EDT -04:00
1.9.3p200 :009 > t
=> Wed, 01 Aug 2012 12:00:00 EDT -04:00
1.9.3p200 :010 > t.zone
=> "EDT"
Finally, a warning -- do not use t.time! It's output is completely useless and irrational, with the time and it's timezone out of sync:
1.9.3p200 :011 > t.time
=> 2012-08-01 12:00:00 UTC