I am saving the Time Zone as 'Default[(UTC+05:30)Chennai, Kolkata, Mumbai, New Delhi]'. As the exact conversion of UTC to Local time is happening in client side (js).
While exporting the DateTime to an excel, I write the coding in appService itself. Due to time conversion is not happening in appService, I am getting the UTC time without converting to my time zone.
I have given date.tolocaltime(); for conversion while running in local source conversion is happening, but the conversion is not happening after hosting the application.
I have hosted my application on the cloud server (Azure)
CASE:
DateTime saved in DB - '2018-03-01 19:11:34.000'
Actual Date - '02-03-2018 00:43:22' (dd-mm-yyyy)
Showing Exported Date as - '2018-03-01'
Better you store time in UTC format in the database and show local time to the end user because it will be unique across all timezone so you will not have to worry about the locale of the user.
You have to options to do this.
Get time from the database and convert it to local time like this.
TimeZone.CurrentTimeZone.ToLocalTime(date);
Convert the UTC time to local time in Angular side before rendering
to the end user. I have already answered here.
Related
Currently my laravel config time zone is set to '+6:00' and MariaDB database time zone is set to SYSTEM, which is +6:00 as well. Now that I need to accommodate users from different time zones, I need to migrate all timestamp values to UTC to avoid any unintended time-related issues.
In MariaDB documentation it is stated that: https://mariadb.com/kb/en/timestamp/#time-zones
If a column uses the TIMESTAMP data type, then any inserted values are
converted from the session's time zone to Coordinated Universal Time
(UTC) when stored, and converted back to the session's time zone when
retrieved.
Now, this is where I am getting confused. What I understand from the above statement that I do not require to change anything in the database as timestamps are always stored in UTC no matter what is my session time zone is at the time of saving the data. Therefore, later on if I update my time zone to UTC in Laravel config, I should get the corresponding UTC value. But after changing the Time zone to UTC in Laravel config I am still getting the time in +6:00 format from eloquent model.
I think I am missing something here and would really appreciate any suggestion regarding this. Thanks in advance.
Is there any way to change the timezone from UTC to GMT+1 in the CRM database.
We have onpremise CRM. The issue we are facing like we have more than 100 reports running directly at crm database.
To convert all the dates to from UTC to GMT+1 will be time consuming and difficult. Also converting all the data time fields to date only is not possible.
As all the users belongs to a single timezone. Can we convert from UTC to GMT+1 in the database it self.
If we can convert what will be impact.
We cannot simply change that, as CRM product is designed to store all the datetime stamps as UTC in database. This actually helps to work/consume/transact by CRM users in multiple timezone without issues.
You should better prepare a wrapper function to convert to local timezone and use the stored values when reading or simply train the user to see it as it is, ie UTC
TL;DR - am I correct in thinking there is no way to determine the timezone used for a given record of a Date field when the server's time zone was changed at some point in the past?
A factory control system was designed to use UTC server (not Oracle) time so all Date columns were UTC. At some point in the past they changed the server time to local. Now years later, they would like the apps to display the correct date. Without knowing the date the change occurred, is there a way to SELECT so all Date records would be correct? I think I can either make the "modern" records correct or the pre-change records correct but not both unless I know when that happened. Since it was a Windows OS change, I don't think even the alert log would help assuming they haven't trimmed it at some point, but it's not easy to get any info or server access from them anyway. It had been 10g and is now 12c.
Correct. Oracle's DATE datatype is timezone agnostic. If you want to store timezone info in the database, use TIMESTAMP WITH TIMEZONE datatype.
I am actually using the mongDB API via a tLibraryLoad component, as I find this easier to build complex multi-level documents using tJavaRow and tJava components, than using the MongoDB palette components.
I am reading in data from Oracle which are date values with a zero time stamp component: For example:
29-JUN-08 00.00.00
The import works via Talend, however the records in mongo shell appear to be the previous day. You can see the record is inserted as the 28-JUN-2008.
Extract from JSON document in mongoDB:
"status_date" : ISODate("2008-06-28T23:00:00Z")
It is almost as if mongoDB (or Talend?) sees a midnight date as the end of the previous day, rather than the start of the 29th June 2008.
In my Talend schema I have specified the Oracle columns as Date types with a DB Type of Date also.
Any advice appreciated.
---UPDATE 1------
As only some dates are affected, it seems this is a DST adjustment in mongoDB to adjust perhaps the display to my local timezone, as the dates which are impacted are in the back half of the year in daylight saving time.
Is it adjusting the date due to the location of the mongo shell?
It is adjusting the date due to the location of the mongo server so all people using the mongo shell would get the same answers to date queries?
Would different people running different mongo queries on dates get different results based on their location, their DST kick in dates...i.e. you could imagine dates from the 1st November 2015, being counted as contributing to October 31st figures (at 23:00)....
i
I feel your pain - this is derived from MongoDB itself.
At issue is that MongoDB stores dates in UTC format by default.
https://docs.mongodb.org/manual/tutorial/model-time-data/
You can use Mongo's suggestion above but in this case you are storing just the date and not the time. I've used two solutions:
Don't bother storing dates as DATEs. Convert all your dates to %Y%m%d format and store them as integers. You can easily compare dates using $gt and $lte just using integers - just be sure to bring in your date using the same format and convert them back in your program later.
... or ...
Since in your case your date seems to be off by an hour, add an hour to it before you make your insert. It all depends on how long the timezone offset is to your local machine.
On linux you can see what the utc value is using:
date -u
I suppose you could change your local timezone on your machine to be UTC time and see what happens.
Personally, I've never had an issue with using the first approach. It's fast and ensures that I have what I want in there.
I think it is because of the timezone of your server. Try to remove the timezone from your date object and then insert it to the mongodb.
With moment.js you can create date without the timezone in such way:
var date = moment.utc("29-JUN-08 00.00.00", 'DD-MM-YYYY h.mm.s').format()
I need to understand how Sybase handles and stores time zones:
For example, if a JDBC client is for example in timezone +1:00 and the Sybase DB is in timezone +2:00:
When the JDBC client application write to the database (e.g. INSERT/UPDATE), will Sybase convert the datetime received from the client application to its local timezone when it stores it in the db table?
When the JDBC client application reads from the database, will the Sybase resultset contain the client or the server's timezone with SELECT queries?
If the DB server box is later moved to another country which is for example in timezone +3:00, will the datetime values stored in the Sybase database become inconsistent with datetime inserted after the move?
So with the above in mind, when do I need to convert date/times and should I convert it to the server or the client's time zone?
Sybase ASE will store whatever time stamp is passed to it by the client application. It assumes that the application knows what it's doing, and will not do any conversion.
This means that the data written and the data read will be based on the client application's time zone, not the database server's time zone.
This also means that you can move the database server where ever you like, without causing inconsistency in the data, since you are using the time set by the application.
My understanding is that Sysbase stores the microseconds from 00:00 1 Jan 1970.
SELECT\READ: returns the converted date (that was stored in microseconds) in the timezone of the host machine.
INSERT\WRITE: inserts the microseconds value based on the timezone of the host machine timezone.
If you move the database and change host timezone, dates returned to the application will change (wich suck), at least the string representation of the date.
My recommendation, have DB and Application always handle in UTC, make the conversion in the presentation layer.