If I want a bunch of contracts to expire at the same time, say all expire at March 30th, 12pm, is it possible to do this? Or is it much more secure to say they expire at block number X?
I found some info here: https://ethereum.stackexchange.com/questions/25170/how-to-do-a-contract-with-expire-time. It looks like the timestamp can be manipulated, so you should avoid using that.
https://ethereum.stackexchange.com/questions/15047/solidity-timestamp-dependency-is-it-possible-to-do-safely/15049
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 want to use days counter in my smart-contract's code.
Is there any built-in constants or good practices to do that?
I tried to play with now and its comparison with timestamp numbers, but it seems pretty unobvious for me.
You can use time suffixes after any integer.
In your case, you can use 1 days which will be converted to an equivalent in seconds.
Take care about calendar calculations however, because in fact not every day has exactly the same amount of seconds because of leap seconds.
You can finf official Solidity documentation about it here:
http://solidity.readthedocs.io/en/develop/units-and-global-variables.html
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
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
As far as Redis do not allow to reSet expire date to key (because of nans with replication) I'd like to know is there any method to check if key set to be expired or not?
Thank you
Use the TTL command. If an expiration is set, it returns the number of seconds until the key expires; otherwise it returns -1.
I don't think checking for expiration date make much sense in Redis, though. I'd like to first suggest that you model it so you don't need to check for expiration date.
If you really need it, though, you can just use another key to store the expiration date for later retrieval via normal GET/SET.
Note that you can also check for EXPIRES manually in your client code, which might be a better solution.