I use the tx_news 2.3.0 to publish article. We did some changes on the page (but the tx_news was not updated) and since then starttime and endtime of news-article acts strange:
It seems like everything works fine with a delay of ~18days. So if I set starttime to NOW the article will be published in 18days. If I set it to NOW-18DAYs it will get published today. The same with the endtime. If I set endtime to NOW-19DAYs the article is published. If I set it to NOW-17DAYs the article is not anymore published.
I checked the date on the server. Also normal content get published correctly when I use starttime and endtime. Also in the backend the article have the small clock on it and there it is right (without the strange delay). What could that be?
As I did not found out what the problem is and it is very illogical I created a work around with a cronjob that handles the starttime and publish the article if current date > starttime.
Related
I'm trying to use a kibana trigger from a monitoring alert using the message box to formulate a kibana link that sends it to a specific kibana dashboard for a time period of the last 7 days from the time the alert is triggered and send it to a slack webhook.
I'm using the ctx.periodStart variable as my ending period. Is it possible to get the exact timestamp that's 7 days from the ctx.periodStart timestamp as part of my kibana trigger message (In other words, if the ctx.periodStart timestamp is 2022-04-11T19:19:25Z as my period ending range, I want to have the beginning timestamp value at 2022-04-04T19:19:25Z)? I can't seem to find anything that can do this. The only way around this issue is to use the ctx.results.0.hits.hits.0._source.timestamp variable as my starting period and that timestamp value is a bit earlier than the exact 7 days from the ctx.periodStart timestamp. Using a relative time period (like now-7d) isn't going to cut it because we fire this kibana monitor alert every Friday at noon to grab a query where we know we will get at least 1 hit and every Tuesday at midnight where we know we are not likely to get any results from the query. And since we know that this alert will go to a slack message with the kibana dashboard link once a week, putting a relative time period like 'now-7d' is going to mess up the kibana links for past slack alerts from the same kibana monitoring alert.
Thanks.
I have a problem with ext:calendarize 6.0.0 in TYPO3 9.5.22:
in my dev-system my day-listings are off by one day:
all events from 14.10.2020 are shown on the next day (15.10.) with correct date in the preview.
After deploying from dev to test system the behaviour changed:
while on the dev-system the events have an offset of one day precise, on the test-system some events are not listed at all in the day-view.
Other views (list, year, month, week) show the events on the correct day.
It's always the day-view which has strange behaviour.
Is there a problem with the query?
I suspect defect timezone handling. Do I need some configuration or corrections for clean handling?
I am facing an issue with setting time on page properties on cq:Page. The time being set into the JCR is getting converted to the timezone that is set in author’s machine. For example: time being set when author is in India is saved as +5:30 while in NY it is being set with -4:00 offset. Is there any way this can be fixed ?
Thanks !
I don't think you want to change this, unless I misunderstood the issue. Time is linear, so at any given point in time, there are as many possible ways to express the time as there are valid time zones. Anyone who views that page information through the application (not directly viewing the JCR) should see that timestamp converted to their local system time.
QuickFIX has a configuration file where you set StartTime and EndTime. Unfortunately AFAIK QuickFIX only supports UTC for this configuration, whereas exchanges are often timezone dependent. This means that you need to remember to update this configuration file every time the clock changes.
Is there a way to set the StartTime \ EndTime parameters programatically instead of through the configuration file? That way you could adjust the timeset the correct values programatically.
There is a way to set this. You can can set a timezone as follows:
TimeZone=America/New_York
see the configuration guide.
It is weird that it is not in the quickfix configuration guide and it is present in the quickfixJ guide.
in our production environment we use always UTC times.
In the QuickFIX config file add for every counterparty the following line:
UseLocalTime=N
Please read the documentation here:
http://www.quickfixengine.org/quickfix/doc/html/configuration.html#Session
as per quickfix docs you should add
set UseLocalTime=Y
Indicates StartTime and EndTime are expressed in localtime instead of
UTC. Times in messages will still be set to UTC as this is required by
the FIX specifications.
We had an error
System.ArgumentException: Only UTC time is supported
Parameter name: oldtime
at QuickFix.SessionSchedule.IsNewSession(DateTime oldtime_utc, DateTime testtime_utc)
at QuickFix.Session.get_IsNewSession()
and the only way to fix it was to delete the store directory. Presumably the session timestamp like this
I'm using GWT on the client (browser) and Joda Time on the server. I'd like to perform some DB lookups bounded by the day (i.e. 00:00:00 until 23:59:59) that a request comes in, with the time boundaries based on the user's (i.e. browser) timezone.
So I have the GWT code do a new java.util.Date() to get the time of the request, and send that to the server. Then I use Joda Time like so:
new DateTime(clientDate).toDateMidnight().toDateTime()
The trouble of course is that toDateMidnight(), in the absence of a specified TimeZone, will use the system's (i.e. the server's) TimeZone. I've been trying to find a simple way to pass the TimeZone from the browser to the server without much luck. In GWT I can get the GMT offset with:
DateTimeFormat.getFormat("Z").fmt(new Date())
which results in something like "-0400". But Joda Time's DateTimeZone.forID() wants strings formatted like "America/New_York", or an integer argument of hours and minutes. Of course I can parse "-0400" into -4 hours and 0 minutes, but I'm wondering if there is not a more straightforward way of doing this.
You could use java.util.Date's getTimezoneOffset() method. It's deprecated, but that's pretty usual for Date handling in GWT currently.
And AFAIR, you can specify something similar to "UTC+4" in Joda time.
Update: I looked it up, and it's "+04:00". Or use DateTimeZone.forOffsetHours() or even forOffsetMillis().
Gwittir (http://www.gwtsite.com) is a library for GWT that includes many cool utilities, like databinding, animation, reflection, and more. However, there are some other interesting goodies as well like the new Joda Time integration. If you have ever been frustrated by GWT’s lack of java.util.Calendar support, you’ll love this, as it makes it easy to do date manipulations in your applications.
otherwise, there are other ways to get timezone offset with + & -.
import java.util.TimeZone;
use: TimeZone.getDefault().getRawOffset()
this function will return the offset time in millisecond about your phone seeting. For Example, GMT-04:00 is equals to (-4)*60*60*1000 = -14400000.
After some operations to get the number which you want.
I have a similar but slightly different problem I think.
I actually need to store the clients timezone on the server, so that I can send out messages about dates stored in their calendar.
The dates are stored in UTC time in google app engine and of course I can store the current Timezone offset when creating the appointment. The problem comes when for instance I want to send out a summary email with a list of upcoming appointments in it. These appointments need to be offset with the correct Timezone adjustments for the client (Im happy to assume that they are still in the same timezone as when they created the appointment).
The real problem comes with Daylight Savings adjustments, so for instance I might have appointments stored for Saturday 30th October 2010 at 1pm (BST[GMT+60]) and Monday 1st November 2010 at 1pm (GMT).
So as you can imagine, I cant just use the current timezone offset (BST) as that would mean that the appointment on Monday 1st November would be listed as 2pm rather than 1pm (GMT+60)
It occurs to me that the best way to deal with this is just to store the timezone offset with each appointment individually, but I feel it would be much better to be able to determine the original timezone correctly in the first place, then just let java do the correct adjustments.