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?
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.
Im a bit new at azure devops and I am trying to view task that was not close in the same day it was activated/ when its state was changed using query. My point of confusion is that I dont know how compare the state change date with the close date.
the output should be tasks that are still active and task that are closed but not in the same date it state was change
UPDATE
So I was wondering if my approach was wrong so I tried different approach.
here I try using the []<> to compare completed date with activation date, it should have sorted to show only task that the activation date are different from the close date but here I still got shown tasks which have close date and activation date in the same date.
UPDATE 2
Since I cant use the '[]<>', I decided to use the not so smart way to compare the task close date, active date, and create date as seen in the screenshot below, it is ugly but it works. If anyone knows a smarter way to do this, please do tell.
My current solution
I still got shown tasks which have close date and activation date in the same date.
The reason for this problem you met is that when you use the condition “Closed Date <>[Field] Activated Date”, the values of these two fields are actually datetime format which means it contains hours, minutes and seconds like below:
That’s why you can still see the records shown with same date.
As for the requirement you mentioned, there’s no directly available solution you can use in Azure DevOps Query as far as I know.
In addition, please refer to Group clauses where you can see how to set conditions for “not close in the same day it was activated/ when its state was changed”, like below:
I am attempting to look at changes through the auditing feature that occur between several hours on the same day on Enterprise Architect Version 13.
This is done through the filter settings where I set the appropriate time range but this does not work as it should. Instead it always returns:
Regardless of any time range I enter within the same day it returns 00:00:00 to 00:00:00 on same day.
Is there a fix for this?
This appears to be a bug in EA. Most likely you are the first ever to use this (silly enough, the date is preset with 1.1.1900 for custom date). The bug is also present in V12. You need to report that as bug.
For example, take this event:
210489449014070 Facebook Event / Graph API Explorer
This event was created back in September 2011. When it was created, it correctly showed Friday, November 11, 2011 11:11pm as the date and time of the event.
But now, it shows Saturday, November 12, 2011 12:11am as the date. This is also happening for future events, such as 426044564103401.
However, it's not happening for even e.g. in the current month like 330237680381087.
Which show the correct date (same as graph shows.) This one was created a few months ago.
My suspicion is that it's still applying the DST offset to the date. For example, right now, pacific time is 7 hours from UTC (because DST is in effect, thus PDT.) On 2012-11-04, DST will end and it will go back to 8 hours from UTC. It "falls back" in fall.
The date on the frontend of Facebook.com is showing as if it's still using the 7 hour offset (it's an hour ahead of what it should be.) My assumption/guess is that at 2012-11-04 02:00:00, it will begin showing the correct date. Hurray? But at that point, the dates that are correct now will probably show wrong (because it won't apply DST anymore.)
I'm guessing this means that internally, timezone-less events are now treated as "-07:00" or "-08:00" globally, based on the current UTC offset, rather than a date-relative one.
Do I have to pull all 186,272 events and update all of them to use timezone dates to fix this (also impacting frontend display to other users, and possibly impacting other parties that are interfacing with these events via FQL or etc.)?
Thanks for any help.
Was probably an issue when Facebook as migrating towards timezone-less events http://developers.facebook.com/roadmap/completed-changes/
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.