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
Related
When attempting to send an event via post to your api in version 4, I am sending
"data"=>
{"id"=>"bfc50100-02eb-11e9-b178-db8890d0b369",
"name"=>"Name of Event",
"type"=>nil,
"description"=>nil,
"start_epoch"=>1343815200,
"end_epoch"=>1343869200,
"archived"=>0,
"deleted"=>0,
"is_public"=>0,
"status"=>"ACTIVE",
"has_time"=>1,
"timezone"=>nil,
"legacy_id"=>nil,
"created_at"=>"2018-12-18T17:38:36.000Z",
"updated_at"=>"2018-12-18T17:38:36.000Z",
"industry"=>nil}}
And receiving success from your API, but when going to the url for this event, I am seeing the date formatted as 1/18/70, though in Unix time this should be showing as 8/1/2012.
This occurs with all dates. Am I missing something? Is there another date format you would like? The term epoch led me to believe that you wanted a standard unix timestamp.
you need to send unix time stamp, e.g., 1545326867 - which is in milliseconds
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.
I have a process that tries to make an SSL connection after start up, but that fails if the clock has not yet been set (the dates don't match the effective dates on the certificates). Is it possible to configure upstart to only start the process after the internal clock is set?
The default setting for the clock is 2010-01-01, so perhaps something like date >= 2014 is sufficient (obviously not legit upstart syntax, but the concept holds).
The best I could figure out was to start up after NTP has started, but that doesn't necessarily mean the clock has been set as the network connection establishment may be delayed or not available for a while.
The simple solution is probably to just poll the date and wait 500ms or whatever before trying again if the date isn't sane yet.
Here's what I ended up doing:
start on started connman
stop on runlevel [016]
script
YEAR=$(date +'%Y')
until [ $YEAR -ge "2014" ]; do
sleep 5
YEAR=$(date +'%Y')
done
python access_point.py
end script
I wait until the connection manager is running and then I check the year every 5 seconds until the year is 2014 or greater.
I want to implement Absolute and Sliding Caching In Redis. Does anyone have any resource link then it will be helpful
Redis already have many commands for this :
EXPIRE : Set a timeout on key.
EXPIREAT : Same as previous but takes an absolute Unix timestamp (seconds since January 1, 1970).
TTL : Returns the remaining time to live of a key that has a timeout
One important thing you have to know about Expiration on Redis : the timeout value is cleared only when the key is removed or overwritten using SET or GETSET. All others commands (INCR, LPUSH, HMSET, ...) will never change the initial timeout.
Absolute expiration is a native feature of Redis using EXPIRE. To implement a sliding expiration you simply need to reset to timeout value after each command.
A basic way to do this could be
MULTI
GET MYKEY
EXPIRE MYKEY 60
EXEC
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"