I've written a report that extracts the data from SQL Azure storage. Looks like DateTime are stored on server datetime (based on South east asia).
When I render the report the date time is very confusing to the users as it's not a local datetime. Could anyone please suggest how to convert the serverdatetime to local datetime in SSRS, please?
Thanks
I think that is not the local datetime but UTC. You can handle all the timestamp and server time by explicitly by converting it to localtime stamp from UTC.
Related
Good day good sirs.
I have a winform application and a Mysql server for the database. In my application, I have several date fields wherein it displays dates of transactions like start date and time. In the application, it is set to follow the date and time of the computer (client) and not the server and when I change the client date and time, it saves as it is and not the server time which compromises data integrity and accuracy. How can i set the client machine to follow the server date and time. Is there any way or techniques to avoid these problem. Like how can i set the appliocation to check if the server and client has thesame date before starting the application. Thanks
When inserting your records in the MySQL database you can use the NOW() function for the datetime field instead of passing in the current datetime from the client machine. NOW() will evaluate on the server and therefore be the server datetime.
https://www.w3schools.com/sql/func_mysql_now.asp
Have you thought about using an EPOCH timestamp?
Unix Time Stamp
Carrying this value instead of datetime values would provide a common base from which to determine the local (client) datetime values.
I have a requirement where I have to load Informatica SESSSTARTTIME(datetime) to SQL server timestamp. When I am trying to connect datetime to timestamp I am getting error incompatible data type.
Any suggestions how this can be achieved?
Thanks
I had a similar issue in the past, where the date column was not getting loaded because of the difference in precision of date/time used by Informatica and SQL server. You can try this workaround: Change the data type in the target definition (not in SQL Server table, only in Informatica Target definition) to String, then Informatica will pass the date/time value in quotes when firing the insert query, which SQL server can convert to date/time automatically.
in the mapping try to create output port in expression as sessionstarttime (which is a inbuilt variable) and pass it to target
hope this will help to get desire output
in session there is config tab where you can change the format for date and time
MS SQL Server timestamp datatype has nothing to do with time. It's an autogenerated number and you cannot load it.
https://msdn.microsoft.com/en-us/library/ms182776(v=SQL.90).aspx
quote:
"Is a data type that exposes automatically generated, unique binary numbers within a database. timestamp is generally used as a mechanism for version-stamping table rows. The storage size is 8 bytes. The timestamp data type is just an incrementing number and does not preserve a date or a time. To record a date or time, use a datetime data type."
I take the UTC date from the sqlserver.
I have to display the local date and time in the report.
How to convert the utc datetime format into local datetime in the expression?
I tried this
=System.TimeZone.CurrentTimeZone.ToLocalTime(Fields!DateTime.Value)
but doesn't work for me
I am pulling data in from an Oracle source (SSIS). After a week of successful run, a timestamp of '6/19/0002 12:00:00 AM' shows up. How do I convert this to SQL server datetime? I am fine with just setting this as null, but how do I detect invalid dates in ssis?
SQL Server 2008/SSIS 2012
I do not have control of Oralce source.
Thanks
I think you are probably looking for datetime2(6) in SQL Server 2008.
Defines a date that is combined with a time of day that is based on
24-hour clock. datetime2 can be considered as an extension of the
existing datetime type that has a larger date range, a larger default
fractional precision, and optional user-specified precision.
Say I have multiple servers in multiple locations and I want to use MySQL's datetime type for the field date and I always want to have the field date have the UTC timestamp so I would execute a UTC_TIMESTAMP() when I add it to the database. Now say I want to have MySQL output the UNIX TIMESTAMP for it.
When I do this on Server A I get the string "2009-06-17 12:00:00" doing the UNIX_TIMESTAMP(STRING) on it gives me the number 1245240000 back. Which is 2009-06-17 12:00:00 in UTC time. Now I do the same thing on Server B.
I get the same string back since its the UTC string but when executing UNIX_TIMESTAMP(STRING) again I get back the wrong number back 1245232800 which is the UTC +2 time. How do I get around this? Should I do the convertion from string to timestamp on the PHP side?
G'day,
I'll ask the obvious here, did you check the date and time on both machines?
Edit: ... and the MySQL timezone was the same on both machines?
Update: Ok. The problem is in the fact that the timestamp string being passed into UNIX_TIMESTAMP is interpreted to be a value in the current timezone which is then converted back to UTC so, because you're in MEZ, two hours is subtracted to return it back to UTC so 7200 is subtracted from your timestamp when it is converted back to a Unix timestring.
Hence, the variation you see when using UNIX_TIMESTAMP() to convert is back to a Unix Epoch timestring.
BTW Shouldn't you be using a TIMESTAMP type for storing off your UTC_TIMESTAMPs instead of DATETIME type?
Update: Decoupling presentation time from stored time is definitely the way to go. You can then reuse the same data all around the world and only have to convert to and from local time when you are presenting the data to a user.
If you don't do this then you are going to have to store off the timezone when the timestamp was made and then go into all sorts of complicated permutations of having to work out if
the local timezone was in daylight saving time when it was stored,
what the difference is between the timezone at the time that the data was stored and the timezone where the data is to be presented.
Leaving it all storeed as UTC gets rid of that.
Most users won't be that happy if they have to work out the local time themselves based on the UTC time returned so systems usually convert to current local time for the user.
This is of course if the user wants the data expressed in local time which is usually the case. The only widely used system I can think of, off the top of my head, that stores and presents its data in UTC is system for air traffic control and flight plan management which are always kept in UTC (or ZULU time to be more precise).
HTH
cheers,
Have you tried doing this?
Execute this instructions together.
SET time_zone = 'UTC';
SELECT FROM_UNIXTIME(0), UNIX_TIMESTAMP('2009-06-17 12:00:00');
// 1970-01-01 00:00:00 1245240000
They only affect the client session, not the server configuration.