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.