Synchronizing MySql Server and VB.Net Winform Application - mysql

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.

Related

Node.js App Datetime stored in Mysql is ahead of UTC time

Columns definition :
`local_punched_at` timestamp NULL DEFAULT NULL,
`punched_at` datetime DEFAULT NULL,
We have an application that is used in multiple timezones, so we are storing UTC time in the punched_at column and the user local time in the local_punched_at column.
When we persist these dates in MySQL the local_punched_at is stored as the same value as punched_at(even we passed the user's local time which is always lower than UTC) or sometimes it is stored value as 1 hour ahead of punched_at value.
For example : For user in America/Chicago Timezone, we send local_punched_at as "2021-11-03 08:52:14" and punched_at : "2021-11-03 13:52:14" , but the DB stored it as
local_punched_at : "2021-11-03 14:52:14" and punched_at : "2021-11-03 13:52:14"
The problem is why the local_punched_at date is changed during saving in MySQL.
MySQL server timezone is UTC.
Node app is running on AWS EC2 and DB is Aurora MySQL.
Did anyone face such an issue?
The TIMESTAMP and DATETIME data types handle time zones differently in MySQL. You are running into that problem.
TIMESTAMP values, when stored, are always translated from the current timezone setting to UTC. And, when retrieved and sent to a client, they are always translated back to the current timezone setting. Functions like NOW() and CURDATE() also obey the current timezone setting.
You can set the timezone, for each connection, with SET time_zone='America/Chicago';. And you can retrieve the current setting with SELECT ##time_zone;
On the other hand, the DATETIME data type attempts no translation. It stores whatever you give it verbatim.
Many global applications ask users to set their preferred time zones, with values like 'America/Chicago' and 'Asia/Kolkata' and so forth. Then, when the application connects to the database on behalf of a user it does the SET time_zone operation. It's a cool feature, for timestamps that lie within the range of UNIX timestamps.
The global application stores timezone-sensitive data (like the scheduled time for a phone call) in TIMESTAMP columns. This allows each user to see times in their local time zone, even when daylight-time changeover days are different between jurisdictions. Like now: England has switched to standard time, but US has not yet. It's based on the Internet Assigned Numbers Authority's wonderful zoneinfo database.
Your confusion here? It's possible your database connection's time_zone setting defaults to 'America/New_York' or '-04:00'. It seems likely your server is located in the US-East region (in the suburbs of DC) of your cloud provider. The time_zone setting does not have to be the same as the server's clock.
If you want to always speak UTC to TIMESTAMP data, use SET time_zone='UTC'; immediately when you open each database connection.

Setting MySQL time zone at runtime with Perl DBIx

I have a Perl Catalyst app that store some times in a MySQL database. The times are of type TIMESTAMP and initialized with NOW().
When reading back the times they appear to be in the databases default time zone. However when using the mysql shell I can easily set the time zone by SET time_zone = '+03:00'; and get the correct local time for my time zone.
Is there a way to set the time one like this in Catalyst or DBIx at run time?
I want to be able to support different time zones, for different users, so just changing the default time zone for the database is not enough. I am also aware that I can format the time in Perl after I get the data from MySQL, but there is so much automation going on with Catalyst, DBIx and Template Toolkit so getting the data correctly from the database to start with would be so much more convenient.
My general advise is to set the datetime in your application, not rely on the datetime of the database server. If you don't need to know which timezone a datetime had when it was set you should store it in UTC. If you need to know the timezone later you need to use a database datatype which supports this like 'timestamp with timezone' in Oracle.
See my answer for Formatting timestamp field for output in TemplateToolkit which seems to be what you're asking.

Using TimeStamp with MySQL, it returns server time instead of local time

I have a MySQL DB, somewhere not sure where it is physically, but I know the column in the table I'm requesting is a TimeStamp and I'm using AngularJS to filter the time like so: {{dateVar | date:'h:mm a'}}. When I get the time back it comes in 3 hours before my local time. My backend is in ExpressJS and it returns the time in this format "2015-07-09T10:57:00.000Z". Any help would be awesome, thanks.
So I figured out why it wasn't returning the proper time, I was sending the server the client time and it was saving that time in the DB but what I should have been doing is saving the server time that way when it sends that time to the client it will do the conversion for you and display the proper time.

How do I change the mysql server date using SQL

I need to change the server date via sql.
Preferably through my application (CL is also good).
How do I change the mysql server date using SQL?
Why:
We test a scenario that spans several weeks. To test it we need to advance the server date by that time.
Do you want to change the server date or the server timezone?
If it is the server date, you have to do it at the OS level.
If it is the time zone, you can change it globally for entire database instance or for your session/connection only.
The SET TIMESTAMP statement affects the value returned by NOW() but not by SYSDATE()

How to store and compare time-zone sensitive times

I have a data structure where an entity has times stored as an int (minutes into the day) for fast comparison. The entity also has a Foreign Key reference back to a TimeZone table which contains the .NET CLR ID Name and it's Standard Time/Daylight Time acronyms.
Since this information is stored as time-zone insensitive - I was wondering how in LINQ to SQL I could convert this into a UTC DateTime for comparison against other times that will be in UTC.
Just to be clear this conversion has to be done server-side so that I can execute filtering on the SQL Server and not the client. The reason for this is to ensure we take into account DST for time zones that support it.
I am using .NET 3.5 SP1 and SQL Server 2008.
Ideally, times should be stored in the database in UTC, and only converted to some local timezone (which would include a DST factor where appropriate) for display. This is especially true if "fast comparison" is your goal.
You might find it easiest to add an extra field which contains the UTC time, modify the clients to add this information, and run a script which one-time calculates it for existing entries.
I can store a CurrentOffset field that will need to be updated by a script that will be updated on the hour, every hour to determine the contextual offset.