I need to convert timestamps of the form yy-mm-dd-hh-mm-ss to a long that represents Unix time. Is there a class in Java's standard library that allows me to do this very easily? Or will I have to code the conversion algorithm myself?
I'm doing this on Android API level 7, in case that environment cuts off some of the necessary Java libraries.
You'll have to parse your timestamp (String.split() may prove useful here) to create a Calendar. From here you can call Calandar.getTimeInMillis() to get the UTC time.
Related
I'm having trouble deciding what data type to use to store dates. I think using the Date type will make it easier for the code to be processed by the backend because there are many functions that can be used. But I'm having trouble when it's used for the response API. Each property of data type Date will return a value in the form of a timestamp. Of course this will require effort for the frontend developer to convert it to the actual date.
I've tried several Rest APIs from well-known vendors out there and then I found they use the String data type to process their Rest API requests/responses. Is using the String data type proper to use on date and time?
REST doesn't have a recommended date format, you should select what works best for your end-user and your system.
Generally, people prefer to use ISO 8601 standard for the date-time values in text. The java.time classes use ISO 8601 formats by default when parsing/generating text.
RFC 3339 Date and Time on the Internet is the document to look at that says:
date and time format for use in Internet protocols that is a profile
of the ISO 8601 standard for representation of dates and times using
the Gregorian calendar.
In your case, you are using epoch for a date which is totally fine and easy to convert to an actual human-readable date using java libraries.
A simple solution would be:
LocalDate ld = Instant.ofEpochMilli(epoch)
.atZone(ZoneId.systemDefault()).toLocalDate();
It all boils down to arbitrary personal preference. I would personally use string since it is easier to read before sending, in transit, and upon receipt.
I'm setting the standards for our application.
I've been wondering, what default date format should I choose to use ?
It should be:
Internationalization & timezone aware, the format should be able to represent user local time
Can be efficiently parsed by SimpleDataFormat (or alike, jdk classes only)
Programming Language agnostic (can parse in java, python, god forbid C++ :) and co.)
Preferably ISO based or other accepted standard
Easy to communicate over HTTP (Should such need arises, JSON or YAML or something in this nature)
Can represent time down to seconds resolution (the more precise the better, micro seconds if possible).
Human readable is a plus but not required
Compact is a plus but not required
Thank you,
Maxim.
yyyy-MM-ddThh:mmZ (See ISO 8601) You can add seconds, etc
You can read it easily, it will not be a problem for SimpleDateFormat.
The most canonical and standard form is probably "Unix Time": The number of seconds elapsed since midnight Coordinated Universal Time (UTC) of January 1, 1970.
If you set that as the default time-format you can easily parse it, store it in memory, write it to disk, easily communicate it over HTTP and so on. It is also definitely an accepted standard, and in a sense it is "time-zone aware", since it is well-defined regardless of time-zones.
(This is the format in which I always store all my time stamps; in databases, in memory, on disk, ...)
The "right" default format really depends on what you're doing with it. The formats for parsing, storing, and displaying can all be different.
For storing the date you're (almost) always going to want to use UTC as aioobe says, even when you want to display it in user local time. I say "(almost)" but I really can't think of a case where I would not want UTC for a saved date. You may want to store the TZ information for where the date originated also, so you can report it in that local time, but more often you want to display the local time for the whoever is currently looking at the date. That means having a way to determine the current user's local time regardless of what the original local time was.
For displaying it, the "default format" should usually be determined by the viewers locale. 08/09/10 usually means 2010-Aug-9 in the U.S. ("Middle endian") but normally means 2010-Sep-8 in most of the rest of the world ("Little endian"). The ISO-8601 format "2010-09-10" is safe and unambiguous but often not what people expect to see. You can also look over RFC-3339 for Date and Time on the internet and RFC-2822 for message format (transmitting the date)
For parsing a date, you'll want to parse it and convert it to UTC, but you should be fairly flexible on what you accept. Again, the end users Locale and timezone, if discoverable, can help you determine what format(s) of string to accept as input. This is assuming user-typed strings. If you're generating a date/time stamp you can control the form and parsing will be no problem.
I also second BalusC link which I hadn't seen before and have now favorited.
I'm writing a app that exposes a REST API. Some of the query parameters will be date/time (accurate to second), and some of the responses will be timestamps (accurate to millisecond).
The API implementation on the server is in Java. The client apps can be anything - java, javascript, .NET. The API returns XML or JSON data. Date/Time data is stored in a Oracle database.
Does anyone have recommendations, based on prior pain, of what the best format format is for passing these date/time values. I'm thinking myself to just use a good old fashioned long to store the number of milliseconds since January 1, 1970, 00:00:00 GMT.
Edit The date range covered in the API is for real time events, so there will be nothing before 2010, and (setting myself up for abuse here) nothing after 2038.
I guess best would be determined by
a) Wide variety of languages support converting this long into internal date object, without having to write code to do it.
b) Lowest CPU overhead (on server app)
ISO 8601 all the way
Using any epoch-based method means you are bound to the range (in most systems) of a signed 32-bit INT (1901-12-13T20:45:52+00:00 through 2038-01-19T03:14:07+00:00) which, is really more of a timestamp than a date, since it can't handle far-reaching historical or future dates.
I need to convert from the Unix TZ environment variable of the form:
stdoffset[dst[offset][,start[/time],end[/time]]]
into a Java TimeZone object.
For example, convert AEST-10AEDT-11,M10.1.0/02:00:00,M4.1.0/03:00:00 into a Java TimeZone object that represents "Australia\Sydney". Before I go and write the code myself I'd like to know I'm not inventing the wheel again, so does anyone know if there's a library already available that can do this?
It will be really hard to write such a conversion program. On Unix, you can have customized daylight rules and Java provides no such facility. It's possible to search through tzfile trying to find a match but you have to convert the TZ rule into the format used by tzfile, an enormous task.
Why don't you use the same zone id used in Java? For example, you can set TZ as,
export TZ=Australia/Sydney
This is supported on most modern Unix systems (like Linux, Mac OS X). Search /etc/zoneinfo or /usr/share/zoneinfo. If you can find a file for your timezone, the ID will work.
I also started on a custom TimeZone to handle the old TZ format but I was able to convince the sysadmin to use the zone id so I didn't finish it. The difficult part is to implement the useDaylightTime() because the rules used in TZ is very complicated.
Is it possible in easy way to convert JRuby Time/DataTime/Data into java.util.Calendar including the timezone?
On #jruby I was given such code cal.set_time_in_millis(time.to_i) but I lost information about timezone in betwean. So the more specific question is how to convert the timezone but I prefered to ask more broad questin in case there is simpler way.
You can use the #to_java method to convert a Ruby time object to a java.util.Date:
require 'java'
Time.now.to_java
Note this coersion happens automatically when passing Ruby objects to Java methods.
I get known that the Time does not store timezone so what is returned by Time.now.zone is local timezone.
Therefore it is simple to convert to java.util.Data:
data = java.util.Date.new(date.to_i*1000)