Ok, I know I must be missing something, but my development server timestamp is off by 4 hours. I am running Mac OS X Leopard Server. The date command in a Terminal shows the correct time. I am in Eastern Standard Time (GMT -5). Is this a devserver setting?
In production google app engine runs in UTC time, so the dev server modifies the timezone to also run in UTC time (although I've seen a case where that doesn't work correctly).
Are you in Eastern Standard Time (GMT-5) or Eastern Daylight Time (GMT-4)?
Related
Is there any way to change SQL server datetime? GETDATE() and CURRENT_TIMESTAMP show the wrong dates.
I read that SQL reads the date from the server settings where the SQL instance is installed. But on this server(Windows SERVER 2019) time, date and timezone are correct.
Only in SQL Server are those settings wrong. I've tried to find a solution for this issue over internet but I couldn't find any.
Only SYSUTCDATETIME() shows correct information.
GETDATE() and CURRENT_TIMESTAMP will be working correctly. They return the server's local time. If the time is "wrong" then it's because the time on the server is "wrong"; most likely because it thinks it's in a different timezone to where it physically is or has the wrong DST setting.
Clearly, however, the time is correct on the server for its location (in the sense of that if it's observing CET it would display 11:38 around now) as you state that SYSUTCDATETIME() returns the correct UTC time.
if the server does have the wrong time setting, however, the fix is fix the time on the server. Speak to your server administrator about that. YOu change change the values GETDATE() and CURRENT_TIMESTAMP return as they are based on the host's time. This is why I am confident the time is correct, likely it is either set to the wrong timezone or DST setting as the UTC time is correct.
If, however, the time is correct for where the server is physically located, then the answer is don't use GETDATE() or CURRENT_TIMESTAMP to get the value for your local time, instead (like you have) use SYSUTCDATETIME() or SYSDATETIMEOFFSET() and then convert the time to your timezone in the application layer.
It seems the server timezone was changed since the SQL Server instance was started. Run the query below to verify the timezone SQL Server is currently using:
SELECT CURRENT_TIMEZONE();
If the result is different than the OS configuration, restart the SQL Server instance for the new timezone to become effective.
Our server is in CST timezone in the USA and CST timezone is 6 hours behind UTC timezone. Since it is daylight saving time, now the difference is 5 hours.
GETDATE function returns the correct local time, but GETUTCDATE returns a wrong UTC time. GETUTCDATE returns the time that is 7 hours (UTC+2:00) ahead of CST.
Checked the server's timezone and it is set to CST time zone (UTC - 6:00) and the option "Set timezone automatically" was off.
I am not sure what else to check for.
"Set time zone automatically" is a convenience added in Windows 10 / Server 2016. It uses available location information to set the time zone. It isn't necessary, and really shouldn't matter on a server. In fact, a best practice is to deliberately set servers to the UTC time zone, so that local time difference don't interfere. You may wish to consider that option.
However, there are a few things to check:
Is your server's clock synchronized to a reliable time source?
If your server is in a domain, then are the domain controller's clocks synchronized to an Internet-based time source or some other reliable time source?
If not in a domain, do you have "Set time automatically" or "Internet Time" turned on? Or some other mechanism for setting the clock correctly?
If not sure where the clock is synchronized, try w32tm /query /source from an elevated command prompt.
If you just want to check the raw UTC time, try [DateTime]::UtcNow from Powershell. (None of the time zone or DST settings will affect the result.)
If the system is configured for a local time zone, is "Adjust for daylight saving time automatically" (or "Automatically adjust clock for Daylight Saving Time" in the older control-panel setting) turned on? This setting should really never be disabled. It is there for legacy purposes only.
If not sure, try tzutil /g on a comand prompt. If the result has _dstoff in the name, then you should go turn it back on.
I'm saving a date in a mysql db as datetime using UTC, so if cst time is 2014-07-22 10:34 am in the db it will save as 2014-07-22 15:34. When testing the app locally, osx 10.9, with either local db or connecting to remote db angular formats it correctly as 2014-07-22 10:34 am. When running the app on a server, ubuntu + nginx + sailsjs, the date reads as 2014-07-22 3:34 pm, so it's not taking into account the timezone. On the server I've set the correct timezone using tzconfig, and it shows local as cst and universal as utc. As I mentioned above, I can connect the local sails app to use the remote database and the time gets formatted correctly. So as long as the sails server is running locally the time is formatted correctly, but if I use the sails app on the server the time is incorrect. Any suggestions?
Thanks
I think your question needs a better explanation. It is hard to tell when exactly the date is messing up. Are you saying that when the sails server is moved to a remote server the date is wrong?
I know personally I stopped using date/time formats and make everything a unix timestamp (ie a NUMBER). This is universal and is never translated till I want it to be translated.
I use this in connection with moment.js (on the server and in angular) to translate my times to/from number and in the correct timezone.
This method has helped tremendously because dates can be manipulated by the server, the db or the client or the db adapter. Maybe none, maybe all and it might event be poor design on my part, but after switching to numbers, I never had these problems ever again.
I am storing a time field in a timestamp without timezone column. The data is stored in UTC time. When I call the data back on heroku I get somehting like 2013-07-13T18:06:41.000Z which is what I want.
However, on my test machine, which is running windows 8 and postgres 9.3 I get this back Sat Jul 13 2013 18:06:41 GMT-0400 (Eastern Daylight Time). This is the right time sort of. It is the correct time with the offset to local time.
How can I match my production db to return the same or similar results to my test db?
It sounds like you want to run your test server with TimeZone set to UTC.
You can set this globally in postgresql.conf, or on a per-user, per-database, per-session or per-transaction basis.
See the manual.
I understood from the GAE documentation that the production server timezone is always UTC. While developing locally, the server timezone is set to CET. Is there a way to force the local development server to also run on UTC ?
The development server is running on Mac OS.
Thanks,
Hugues
jut found the answer. In order to set the server timezone, just go in Eclipse, "Run configurations", then "VM arguments" and add the following "-Duser.timezone=UTC".
This will set the server timezone to the value you want (UTC) in this case. This is really handy as Google App Engine production will always run UTC whereas the development server (at least in my case) was running with local timezone. The net effect was that I had a different behavior between dev and prod.
Hugues
Well you can use this while saving a date value to your datastore to convert to your specific timezone.
DateFormat utcFormat = new SimpleDateFormat(patternString);
utcFormat.setTimeZone(TimeZone.getTimeZone("UTC"));
DateFormat indianFormat = new SimpleDateFormat(patternString);
utcFormat.setTimeZone(TimeZone.getTimeZone("Asia/Kolkata"));
Date timestamp = utcFormat.parse(inputString);
String output = indianFormat.format(timestamp);
GAE devServer uses local Timezone by default.
I use this code to force it to UTC:
boolean isDevEnvironment = SystemProperty.environment.value() == SystemProperty.Environment.Value.Development;
if (isDevEnvironment) {
TimeZone.setDefault(DateTimeZone.UTC.toTimeZone());
DateTimeZone.setDefault(DateTimeZone.UTC);
}
You need to run it once, in the very during server startup and initialization.