I have centos server and i rechanged the time to NewYork time by date cmd.
Also i change in php.ini the "date.timezone = "America/New_York""
When i enter the command date in the command shell. i get the real time in new york.
But when I do
echo date("Y-m-d H:i:s");
The time isn't right!
I always get 6 hours less then the time in New York.
Please help?
I tried already using date_default_timezone_set('America/New_York'); in the code with no help.
waiting for a response.
Thanks!
Koren Or
i rechanged the time to NewYork time by date cmd
The date command doesn't provide a means to change the timezone. You probably set it to the time that it is in new york time, but as whatever timezone it was already set to, so you ended up with the server time being six hours off (odd, it should be five off if it's UTC).
Set the TZ environment variable export TZ=America/New_York before setting the time with the date command. Having an incorrect server time can lead to serious problems.
You can initialize the timezone in your app. What happens when you do this?
date_default_timezone_set('America/New_York');
echo date("Y-m-d H:i:s");
i change in php.ini the "date.timezone = "America/New_York""
Look, it is very common fault of people who aren't familiar with a formal logic.
Let me show you using a little example:
Suppose you just put some money into your pocket.
I come across and asks you if you got any money in your pocket.
You says "Yes".
But you can't say it for sure!
You can tell for sure only that you put it there.
But there can be a hole in the pocket or some thief picked it already or you just confused pockets.
So, you have to check it first, and answer later.
Although it is negligible in the real world, in programming such a behavior become critical!
You can change whatever settings but you have to verify, if your actions had any effect
There can be an apache reload issue, or wrong ini.file or some runtime setting overwriting it.
Tl:dr
Always verify your settings, variables, data - if it really contains expected value!
Do not rely on the fact you changed it somewhere.
This sounds like an issue with not actually setting the timezone correctly on your machine.
First, to verify PHP is using the correct timezone, try the following to see.
echo date("Y-m-d H:i:s e");
That should give you "America/New York" if you have set it correctly in your script.
If so, I would try the procedure discussed here to change the time on your system and see if that works.
I'm just guessing here but do you restarted your apache server?
Related
We have a dataset in Firebase updated by multiple clients.
We want to track the last modified on datetime of the dataset. We cannot rely on the client setting the modified on datetime as their local clock can be totally out of sync.
Is there a way I could have Firebase tag timestamp to a dataset based on its clock to track last modified on?
We're working on some features to support this at the moment, but we don't have a way to do this right now. Note, however, that the IDs created by "push()" are chronologically-ordered, and we compensate for client-side clock skew as best we can when we create them, so if all you're trying to do is make sure some writes to a list occur in order, you can do that with push().
I'd be interested in hearing how you'd like this feature to look. If you have a sec I'd appreciate an email to andrew at firebase...
Update: Firebase now supports setting server timestamps as well as accessing the server time directly on the client. See the documentation here:
https://www.firebase.com/docs/managing-presence.html
We're on the same boat... and I guess sooner or later, many firebase clients will have this issue, as it's a "new kind" of problem we never had to face in the old "client-server" days.
Out current solution (still in the making) is to estimate the time difference between the client and OUR server on initialization, and them compensate,
So - where we had x = new Date(),
it is now x = ourDateService.now()
our now() function simply does new Date() + diff
This works for us,as we don't need millisecond accuracy, and it's a single-page-app that loads once, so we can do this diff-check and initialize ourDateService on load, but this solution will not work for everybody (ofcourse, you can store it in the localstorage/cookie and revalidate every day or so).
Basically I am trying to find a way to convert datetime of a particular timezone to other timezone while taking DST into consideration too. e.g.
What is the time in "Central Pacific Standard Time" when it is, say, 2012/9/29 9:00AM in "Tokyo Standard Time" ?
I found some solutions on the Internet to convert local machine time to other timezone.
$ToTimeZoneObj = [system.timezoneinfo]::GetSystemTimeZones() | Where-Object {$_.id -eq $ToTimeZone}
$TargetZoneTime = [system.timezoneinfo]::ConvertTime($datetime, $ToTimeZoneObj)
I am thinking if I can create a datetime object of a timezone different from the local machine, I can then use the solutions I found, or will there be other ways to do what I need?
Thanks
This solution worked well for me:
$cstzone = [System.TimeZoneInfo]::FindSystemTimeZoneById("Central Standard Time")
$csttime = [System.TimeZoneInfo]::ConvertTimeFromUtc((Get-Date).ToUniversalTime(), $cstzone)
You can then manipulate the $csttime variable just like a datetime object:
Get-Date $csttime.AddHours(-1) -f "MM\dd\yyyy HH:mm:ss"
References:
http://msdn.microsoft.com/en-us/library/system.timezoneinfo.converttimefromutc(v=vs.110).aspx
http://technet.microsoft.com/en-us/library/ee692801.aspx
Working with TimeZones can get pretty tricky. Thank god for the updates they added in .NET 3.5 and 4.0. I worked on several time zone projects and in 2.0 is was nearly impossible without iterating the registry and building your own list of TimeZones.
Now you can get a list of TimeZones by using the TimeZoneInfo class (which you seem to be familiar with):
http://msdn.microsoft.com/en-us/library/system.timezoneinfo.aspx
Just beware that a system that may not be updating automatically from Windows Update could potentially have different time zones than a system that is totally up to date. Microsoft pushes out updates for time zones when needed.
I think your code seems OK. To be honest, I'm not much of a PowerShell dev (C# for me), but it seems good.
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 trying to write some code that checks the number of days between two dates, when I set the date on my IIS7 server to anytime in the future I get the standard "Internet Explorer cannot display the webpage" screen. This happens if I comment out all my date checking code, with todays date it loads with any future date it doesn't. I've tried rerunning IISReset which makes no difference.
Anyone seen this before?
Thanks
Jamie
You've proven that you can retreive the current system date from the server.
IMO, now you can go ahead and fudge the numbers by reading test dates from a file (override.txt, or whatever) and test your date calculation scenarios without having to mess with the server.
You will want to make sure that you have a common function for getting the system date, so that you can override in one spot. So if you're not already set to do that, re-tool the code a bit, re-test to ensure that you get the system date properly. Then drop in your override file and test away.
GWT doesn't serialize Java Date properly. When I tried sending Date created in Javascript through the wire, I found out that dates between April 1st (funny) and 25th October for years before year 1983 get subtracted by one day.
That means that, say, both 1982-04-01 and 1982-03-31 become 1982-03-31 on the Java side.
Given the dates in question, I would guess that this is some kind of DST problem. I've tried googling, and found only one other reference that describes similar problem.
I also tried submitting bug to the GWT team, but curiously wasn't able to find bugtracker for GWT.
So, my questions are:
Anyone else run into this? I'm on GWT 1.7, and would like to confirm if this happens on 2.0 as well.
My workaround was to send dates as Strings, and parse them on server. Anyone knows better workaround?
Assuming that you are using a java.util.Date
Question 1: It seems that it is fixed in 2.0. I've created both Dates above (1982-04-01 and 1982-03-31) and they come through correctly to the server (both represent on the server as 1982-04-01 and 1982-03-31 respectively). My setup is:
GWT 2.0
Java 1.6
OSX 10.6.2
Question 2: You could always pass the 'milliseconds since January 1, 1970, 00:00:00 GMT' over the async service-which you can get using getTime() on the date object. On the server side you can then instantiate a new Date passing this value in on the constructor:
Date date = new Date(millis);
This saves fiddling around with formatters and parsers.
Dates and times are a complicated subject. The conversion can depend on the locale that the browser is running in and wether both you JVM on the server and the locales of the clients are up-to-date.
In some cases there can be differences because in some regions they switched timezones in the past.
GWT sends dates using just millis since epoch time. Since it is using Date objects, you are limited in that the Dates on the server side will be automatically modified to the servers timezone. Are you sure that you take into account the possible difference in timezones between client and server ?
David
I'm pretty certain the FTR library has some date emulation in it.
http://code.google.com/p/ftr-gwt-library
If you don't have to do client-side conversions (adapt to user's timezone) or calculations send it in a String from the server.
Never came across your specific problem though.
The possible problems soure is difference in Client/Server time zones.
We have also run into a similar problem. It was long enough ago that I do not remember the exact details but the gist of it was there were some minor differences between java.util.Date and the way dates were handled in Javascript. Our workaround was effectively the same as yours, where the actual value sent over the wire was generally a String.