I am getting issue with my current WordPress installation.
Whenever anybody posting any comment on a blog, the time is less than 2 hrs of the current time of posting. I have checked the server time and it is showing properly in php and mysql both. But still when each comment posted, the comment_date column of wp_comments table inserted value with 2 hrs subtracted value.
http://en.support.wordpress.com/settings/general-settings/
Timezone is set to Coordinated Universal Time, UTC by default...
Related
Whenever I try to save a post in the future, the time will detract 2 hours. This seems to be a timezone issue, but I cannot figure out what causes this.
My server timezone is set to Europe/Amsterdam, as well as my WordPress timezone.
If I want to save a post for 18:00 today, it gets saved as 16:00.
Can anyone point me in the right direction as to where to look?
What time zone are you in? Does it happen to be 2 hours apart?
Can someone give little clarification how to interpret following parameter:
deletionRequestTime: datetime`:
This marks the point in time up to which all user data for the specified end user and Google Analytics property or Firebase project should be deleted.`
If I set it to 1st Jan2018 (GTM), does it delete all user data:
from that date till today (which is how I interpret).. meaning all 2018 data will be gone?
or, (from epoch time) till that date ... meaning all 2016/2017 etc. data is gone and all that remains is 2018 data?
When trying the API > refreshed User Explorer report in GA interface > I notice all-time data seems is gone (giving me impression that this filed is not respected?). But let me wait 72hrs since API request to draw any conclusion..
Thanks for any clarification.
Cheers!
First off i dont think your miss-interperting it I dont think the documentation is clear.
The following is from userDeletionRequest
deletionRequestTime datetime
This marks the point in time up to which all user data for the specified end user and Google Analytics property or Firebase project should be deleted.
Now to me that means that its a point in time that the data should be deleted. as in one day? one minute a time stamp? would this then mean you will need to loop though every hour minute in a day to delete everything.
My current answer is this is confusing. I am going to contact the team for clarification they are in West coast USA we wont get an answer back for several hours. I will updated this when i know more.
Clarification from Google
As per documentation, deletionRequestTime represents a timestamp up to
which all use data will be deleted. In other words, all data from the
beginning of time until the point returned in deletionRequestTime will
be deleted.
I don't believe you can set the deletionRequestTime field. It is set to the time you make the call.
I believe that is why you are seeing this behavior.
Within the Paw App, I consider the Cookie Jar as a template for common session scenarios. Set up "n" number of sessions, set their domain and name, and save for future use. The session values need to be updated, no way around that.
However, when creating a Cookie Jar, how do you set the expiry date? The date seems to be auto-filled for a few hours in the future (mind you the date seems to be wrong anyway - see screenshot, noting the year 4001 and the day being 2 days prior to present).
Ideally I would like to set it to say "+2 weeks" - because the alternative it completely clearing out the Cookie Jar every few hours to create new dates, which means re-creating the name, domain and value attributes everytime.
EDIT: Ignore the year 4001, it appears to update after saving and moving away from the modal. The original question stands about updating expiry dates
EDIT EDIT: The 4001 is still appearing
EDIT EDIT EDIT
With the current state of the Paw app (2016-01-30) this can't be done. However the team are actively working on the app, so I will update this answer in the future
We have a really strange problem in xpages regarding dates, the Notesdocument we have contain a date field and the value is only a date, there is no time portion.
In the xpage I have specified to display the date as a date/time value. the date display correctly on the webpage but we are now getting reports from users who login at night (around midnight) and see the date as adjusted by one day. if the same people login at daytime the date is correct so this only seem to happend around midnight
I have tried to change my clock on my client to around midnight but that does not reproduce it so I assume this is a server issue.
The domino server have correct date/time and we are using the latest version of Domino
any ideas?
we encountered the same problem recently and, I believe, found a very nice solution.
system treats the pure date as a date in UTC time zone. Date value is automatically converted into server's time zone. So the question is how to prevent conversion?
this code prevents conversion:
<xp:this.converter>
<xp:convertDateTime
type="date"
ignoreUserTimeZone="true"
dateStyle="long"
timeZone="UTC">
</xp:convertDateTime>
</xp:this.converter>
pay attention at "timeZone" attribute.
The issue is related to not having the TimeZone specified in the date / time field. We ran into this just yesterday. If you don't have the TZ specified, it seems to assume UTC and will adjust accordingly. Include the time zone and your field will stop adjusting erroneously.
Perhaps it has to do with this ?
http://www-304.ibm.com/support/docview.wss?uid=swg21508734
I've seen some reports about XPages Dates and TimeZone Issues
I suspect your Domino version was 8.5.3, because there were 2 APAR, LO72278 and LO67745, on similar problems against 8.5.3. Fixpack 3 addresses them.
The root cause is that Lotus Notes allows you to save a "Date" with no time or zone and the Notes server has a default Time Zone setting to interpret these incomplete things called dates. XPages doesn't play by the same rules, and its master Java wants to know what zone you're using, and looks to the system for some clue, and generally will use midnight within some TZ to refer to a "Date". There is a whole region on Stack Overflow on the "how to store/represent a date" topic - [datetime] - since languages and DBMS each have their own approach.
Nice legacy Notes focused article about it.
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/05022009100728PMAGU5MB.htm
XPages article about it
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/XPagesTimeZones.htm
Too bad they are not totally on the same page, I assume each release gets closer.
I'm making a timeline in Wordpress, and I'm trying to make a post with the date January 12, 1800, but Wordpress doesn't allow me. Apparently, it doesn't let me post anything before the year 1970. Is there any way to fix it?
PHP (the programming language WordPress is written in) uses a unix timestamp, which is the number of seconds since the 1st January 1970. This means that you can't use dates before that date, as that's "the beginning of time" according to PHP.
Sorry if that wasn't the answer you wanted :(
I'm fairly sure this isn't a Wordpress problem, more specifically a PHP problem which has led to Wordpress dealing with it.
This excerpt is taken from the PHP Manual:
The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer). However, before PHP 5.1.0 this range was limited from 01-01-1970 to 19-01-2038 on some systems (e.g. Windows).
So it may not be a problem with Wordpress itself, you may need to get in touch with someone at Wordpress about the problem, perhaps they can implement PHPs calendar extension.
Here are two solutions I came up with:
http://studiohyperset.com/wordpress-old-dates-historical-pre-1969-pre-1970-timestamp-function/3102
If all your dates are going to be in the 1800s, perhaps you can configure Wordpress to show the date in 2 digit format and stick "18" before it.
Some people claim to be able to use pre-1970 dates, though the bug is still offically open for 3.0: WordPress › Support » Bug with backdated post before 1 January 1970 - wp2.8 It's alleged that the problem is the se of negative time stamps, which some server OS's can't handle.
Could a custom field be used for the year earlier than 1970 and while printing the "current" day and month?
You can put the date into a custom field and display that instead and you could sort by that custom field as well, so the end result wouldn't be any different.
You can use Custom Fields to store the date, and show that in place of the_date or the_time calls.