I try to update application in TWSz via Java API but when application has defined run cycles with Out of Effect date set to 71/12/31, TWSz returns error:
EQQX375E THE RUN CYCLE VALIDITY END 720101 IS INVALID OR BEFORE/AT THE START
In every application, before update, it I have to check that there is run cycles and if are, check the Out Of Effect dates. If OOE == 71/12/31 update it to 31-12-71 using setValidTo but this is very inconvenient. Is there any other way to update application without updating Run Cycles?
It looks like that going forward and back, the date gets an additional day, wrapping to the TWSz minimal date 720101 (Jan 1st, 1972).
Do you make any conversion of the java Date that is returned by the API before send it back to the update?
I suggest to verify the date and time of the Java Date that is returned by the API on the get, and compare it with the Java Date that you are passing to the update.
For TWSz APIs, the Java Date object that contains a date without a time (like the validTo) should be set to the midnight GMT of the date they represent.
Related
Generating a passbook file using passkit4j with relevance date of today and no expiration date.
However, the pass in apple wallet seems to expire after a day.
Question:
How can I make pass with no expiration date
What is relevance date ?
Tried changing expiration date to multiple different values but doesnt seem to work
Not sure if this helps, but according to Apple's documents, Relevance Date has no meaning for store cards.
https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/PassKit_PG/Creating.html
Check Table 4-2
I read somewhere that some versions of iOS uses the relevantDate as expiration date for a pass.
Otherwise use the expirationDate property
I think there is a bug when querying a release's ReleaseDate field. Let's say I have a release with a ReleaseDate of 04/24/2017 EDT, when I get the response from the API request, and take a peek at the ReleaseDate field for that release, it comes off as 04/25/2017 (in date time format obviously), one day ahead of the actual date. I am building a calendar app for inside use using full calendar, and this bug is really annoying. Am I correct to say that this is a bug? Are there any workarounds that do not involve writing code to fix the date after querying it? thanks.
Pretty sure this is timezone related. Dates in WSAPI are always UTC. Assuming your workspace is configured for Eastern the dates returned probably are the next day:
A release with an end date of 04/24/2017 is probably being returned from WSAPI with a date like 2017-04-25T03:59:59.000Z, which when converted to EDT would be the end of the day on the 24th.
You'll also want to be specific when setting dates since the backend will again try to coerce the date into UTC if there is no time specified. The current behavior or the detail pages is to set it to noon on that day for that timezone. So something like this: 2017-04-24T12:00:00-05:00
Hope that helps. We did a bunch of work across the product and the api's last year to try to provide a more consistent experience working with timezones. It still can be confusing, but a good rule of thumb is to always be specific and include a time and timezone offset when working with dates using the api.
If you're using App SDK, the moment.js library is already included and is super handy for working with dates:
https://help.rallydev.com/apps/2.1/doc/#!/guide/third_party_libs-section-moment.js-2.10.3
The documentation here states the below
This option allows you to define an expiration time for the message.
To define an expiration time based upon the time a message entered the
flow, enter a Mule Expression to call a variable that provides this
date and time in ISO 8601 format (yyyy-MM-dd'T'hh:mm:ssZ), and an
expiration time in milliseconds. (Earlier in the flow, you will need
to name and define this variable so that it extracts the date and time
information from your message's metadata.) The expiration time will be
calculated based on the timestamp extracted from the message, and the
filter will discard messages received after that expiration time.
To define an exact date and time after which messages should expire,
enter a date and time in ISO 8601 format (yyyy-MM-dd'T'hh:mm:ssZ), and
an expiration time in milliseconds. The expiration time is calculated
from the precise date and time you enter, and the filter will discard
messages received after that expiration time.
I can't understand how this filter works ?, What kind of usecase would warrant this filter ?,
My take on the use of the filter is as below, And I think its wrong but for what its worth I am putting it down here ...
The filter is used to kill messages that take more than "X" milliseconds to be processed by the flow
To use it do the below
The message created date should be stored in a variable right when the message enters the flow and then use the filter somewhere down the flow, the filter will reference variable (created earlier) and a "expires in" value to check if the current time is less than (variable created earlier + expires in) .. If true let the message proceed else remove the message.
I am trying to use the listdata.svc to retrieve list items and one of the filter parameters is a datetime field. So the request looks like this:
http://moss2010/_vti_bin/ListData.svc/HeadLineNews?$filter=Active
eq true and EndDate ge datetime'2012-01-11T18:00:00'
I am getting items back with "EndDate" set to earlier time back from the request such as the following:
<d:EndDate m:type="Edm.DateTime">2012-01-11T12:00:00</d:EndDate>
I have tried to change the time in the EndDate parameter around in case this has something to do with client browser's timezone settings( I have changed "18:00:00" to all 24 hours between "00:00:00 - 23:00:00"), but this doesn't seem to be making a difference. However as soon as I change the date to a day earlier "2012-01-10T18:00:00", it would start to return correct items.
Is it a known issue for ListData to ignore the time information for DateTime fields? Anybody have run into this before?
I have October 2011 Update on my SharePoint server.
I believe this is a known issue - or yet another gotcha in Sharepoint. I see the same behavior and have seen blog posts to this effect. My first thought was that it had to do with UTC vs local time. I've tried a variety of ISO 8601 formats for UTC and timezones, but in every case it seems to ignore the time component. The only workaround I can think of is to go ahead and return the whole set, then filter in whatever is consuming the data.
https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators
I have been trying to find the answer to this for several hours... what timezone does the Magento API use? I am assuming that the Magento API returns all date values as GMT time because they do not append the timezone string at the end of the data. Is this correct?
I am wanting to use filters and want to make sure that the dates are being correctly interpreted in my offsite client.
From my experience, all dates in Magento seem to be stored in GMT. You should be able to confirm this trivially in any particular case by adding a record at a known time and calculating the offset.