I'm having hard time to decide on the right approach for data saving from different time zones:
I'm building an application that supposed to serve users from all over the world.
I have a table named Events which saves events the users inserted.
In this table there are Start_Time and End_Time columns of the event, which I some time need to run a select query according to does columns, and in relevant to user's current time.
I'm thinking about what the best approach for saving does times in the database. obviously I have some lack of knowledge in the time zones field.
For now i'm saving all the times as current UTC time stamp, and i'm not sure that its the right way to do so.
can anyone please provide some guidelines or documents about to right way to store it ?
hey according to my understanding you have a application that send request to this database on behalf of user, and user has its own date and time zone.
I would recommend to change your request time zone on application level to UTC. bring your application and database to same page and then after processing you can convert it back to local time zone.
what application language your are using?
Related
Is there a good way to surface when a dataset backing an object was last built in a Workshop module? This would be helpful for giving users of the module a view on data freshness.
The ideal situation is that your data encodes the relevant information about how fresh it is; for instance if your object type represent "flights" then you can write a Function that sorts and returns the most recent flight and present it's departure timestamp as the "latest" update, since it represents the most recent data available.
The next best approach would be to have a last_updated column or similar that's either coming from the source system or added during the sync step. If the data connection is a JDBC or similar connection, this would be straightforward; something like select *, now() as last_updated_timestamp. If you have a file-based connection, you might need to get a bit more creative. This still falls short of accurately conveying the actual "latest data" available in the object type, but at least let's the user know when the last extract from the source system occured.
There are API endpoints for various services in Foundry related to executing schedules and builds, but metadata from these can be misleading if presented to users as an indication of data freshness because they don't actually "know" anything about the data itself - for example you might get the timestamp of when the latest pipeline build started, but if the source system has a 4 hour lag before data is synced to the relevant export tables, then you'll still be "off". So again, best to get this from inside your data wherever possible.
I am trying to realize a project where people can login into a site where they find a personal calendar. In this calendar people shall be able to leave timestamps. Since a year has around 365 days, (and per day more than 1 timestamp is possible) there will be a lot of timestamps to save.
I need a way to save those timestamps in a sort of database. I am new to this and I want to know if using a JSON File for storing those timestamps or using a MySQL database is the better way of doing this.
Background-Story:
I work on a project where a microcontroller does certain things at those given timestamps from the User. The user leaves timestamps in a calendar on an iOS-App. So it also has to be compatible with Swift/iOS.
Any ideas?
Databases have a few ways to store timestamps. For example the data-type TIMESTAMP or DATETIME are all ways to store timestamps
If you do it in a database, you have the ability to sync it across devices.
To do it in JSON, I'll refer you to this question on StackOverflow:
The "right" JSON date format
EDIT: After reviewing the comments, you most likely want a database. I have an example here where you have a table for users and a table for events that can be joined to get each event for each user, even though each user has all their events in the same table.
I created this because I used to not know what Databases were good for, so I came here and someone put me in the right direction. Databases are VERY powerful and fast. To maintain everyone's JSON file of events would be a nightmare. I 100% recommend a database for your situation
Play around with this sample DB I created: http://sqlfiddle.com/#!9/523e2d/5
If you have only a few users with a few timestamps and not much else going on, then you could indeed store each user’s data in a text file. That file could store JSON if you want, or XML, or more simply tab-delimited or comma-delimited text. If you just need the next timestamp, without keeping history, this might well be the best approach with one file per user. Beware of risks such as your own code inadvertently overwriting a file, or crashing during a write so the file is ruined and data lost.
A step-up from text-in-a-file is SQLite, to help you manage the data so that you need not do the chore of parsing. While SQLite is a valuable product when used appropriately, it is not meant to compete with serious database products.
But for more heavy-duty needs, such as much more data or multiple apps accessing the data, use a database. That is what they are for – storing large amounts of structured data in a way that can handle concurrent access by more than one user and more than one app.
While MySQL is more famous, for serious enterprise-quality database where preserving your data is critical, I recommend Postgres. Postgres has the best date-time handling of most any database, both in data types and in functions. Postgres also has the best documentation of any SQL database.
Another pair of options, both built in pure Java and both free-of-cost/open-source, are H2 and Derby. Or commercial products like Microsoft SQL Server or Oracle.
You have not really given enough details to make a specific recommendation. Furthermore, this site is not meant for software recommendations. For that, see the sister site: Software Recommendations Stack Exchange.
If you choose a database product, be sure to learn about date-time handling. Database products vary widely in this respect, and the SQL standard barely touches upon the subject. Quick tips: Store values in UTC, and indeed your database such as Postgres is likely to adjust incoming values. Apply a time zone only for presentation to users. Avoid the data-types that ignore the issue of time zone. So for standard SQL, this means using the TIMESTAMP WITH TIME ZONE data type rather than TIMESTAMP WITHOUT TIME ZONE. For Java work, use only the java.time classes rather than the troublesome old date-time classes, and for your purposes use the Instant and ZonedDateTime classes but not the LocalDateTime class which lacks any offset or time zone.
In my web application like eCommerce site. Every projects have time limit.I will display time left details in each and every projects.i am using UTC time.how to convert current localtime for every users.For example, USA have 4 or 5 different time zone.i am using php codeigniter and mysql for my web application
If I was you, I would keep all times on your server side UTC and only convert to local time in the client via JavaScript. However, dealing with client time is tricky, since you can't really know their wall time.
I have seen 3 approaches:
1) Use var offset = new Date().getTimezoneOffset();
Probably the best way of getting the client system timezone in an automatic fashion.
2) Try to figure out the timezone by the client IP.
If you need to do the time rendering on your server after all, this might me the only automatic way you can do it. It is very error prone though, because your clients might be using proxies, VPNs etc. Also, the geoIP databases might not be accurate enough.
3) Let the user set the timezone.
This is playing it safe. the user can decide. You can also kepp the setting in a cookie or such.
The momentjs timezone library might help you with all three approaches.
I'm developing an app that meant to run only in Israel.
All of our tables contains times at Israeli time (Tel Aviv time).
because the SQL in GCP doesn't support default timezone and time zone convert I got stuck.
how can I convert times between time zones?
let me remind you that Israel has a light saving time change.
Now you have the ability to set the time zone in Cloud SQL. See https://cloud.google.com/sql/docs/mysql-flags. The limitation is that the time zone needs to be specified as offsets to UTC, such as '+10:00'. It does not support named time zones like 'Europe/Helsinki'.
Cloud SQL now supports named time zones. See a list here: https://cloud.google.com/sql/docs/mysql/flags#timezone-names
When using timezone names, automatic adjustment to daylight saving time is supported.
What is weird is that even though when explaining named time zones it gives the example Europe/London, in the actual list that's missing. The closest equivalent is Europe/Dublin, which is functionally the same although their summer time is considered "standard" so they switch to winter time.
THIS ANSWER IS OBSOLETE
On Google Cloud SQL you cannot currently set your own time zone. If you need to change the time zone on your instance, please get in touch with cloud-sql#google.com.
I have a web server which will be serving people from around the world.
The time is a really important matter in my application, since a lot of queries are taking the time in consideration.
I need a way to store user's and server's time differences.
For example:
User login to server and send its current time.
Server's save the current time difference in mySql server
Every every time the server needs to use user's time in a query he knows how to calculate it since
it knows the difference..
What i really need is the server's ability to calculate user's time according to server's own time.
I've read about using UTC time but i didn't really understand how to implement it...
Let's say you are in the US and i am in the UK. If we both check the UTC time at the same time (with whatever code/method) we should see the same result. Check out the different ways of getting UTC timestamps in milliseconds. Then, in theory, if you sync everything by UTC time (including the server) you don't really need to be aware of timezone offsets because these offsets are only relevant if you consider the server time is based on its local timezone.
In MySQL you can get a unix timestamp with UNIX_TIMESTAMP(). As far as i know it has granularity to the second, not millisecond (so you will get the number of seconds since 1970). You can also check out UTC_TIME() and UTC_TIMESTAMP().