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.
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.
Im developing an app thats hosted up in Azure. On my development machine when i edit and save dates (UK format - saving to local sql server 2012) theres no problem. When I deploy the same code base to Azure (same database structure & sql server version - db hosted in VM in Azure) Im getting an error
'the value 23/01/2014' is not valid for contract date
has anyone else experienced anything like this and could give me some pointers ?
Ive set the os on the VM machine to be uk region and the underlying dates in the tables both locally and remotely are exactly the same format. Is there anything obvious I could be missing ?
the value 23/01/2014' is not valid for contract date
Please run dbcc useroptions to check the language and dateformat. And by default, the date format for SQL server is in U.S. date format MM/DD/YY, unless a localized version of SQL Server has been installed.
You could try to use the international format YYYYMMDD for sending the datetime data to SQL Server or pass the date in date format being used on the SQL Server.
I have an issue where all dates in parameters are displayed as mm/dd/yyyy:
My goal is to change the date format to dd/mm/yyyy, which would require changing the locale to English-GB. Things which I've currently tried (and didn't work):
Changing the Language within the individual report settings to English-GB
Checking the Windows locale setting on the SQL Server instance (it was already set to English-GB and dd/mm/yyyy)
Changing the default SQL Server language using EXEC sp_configure 'default language', 23 ;
Changing the Reporting Server's service account language using ALTER LOGIN [XXXXX] WITH DEFAULT_LANGUAGE = British
Restarting the Reporting Service
Killing all connections to the SQL Server instance to force a reconnect
Non of the above worked and I'm still seeing the dates in the wrong format. Is there anything else I can do?
I think actually this comes from the Language of the browser rather than Report Server - I could be wrong. Try changing from US English to GB English in IE or whatever you're using.
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.
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)?