I need to bind a Date using the milliseconds representation in a controller (i.e. milliseconds from 01.01.1970). I tried using #As("S") but had no success, it fails as soon the value is at least 1000. Is there really no way to do this without writing a custom binder?
Edit: Seems like writing a custom binder is the way to go because Play's DateBinder uses SimpleDateFormat and because of this bug. SimpleDateFormat doesn't accept these kinds of formats.
AFAIK there's no way, because the binder is just trying to parse expecting the date fields (and the Date millisec field are just 3 digit), and it will not calculate anything.
It's better to bind millisecs to Long and then create Date with it.
Related
What is the best way to represent a time field in a swagger specification, the closest type to denote it looks like date-time but this makes standard deserialisers to expect date field to be passed along with the time... Is there a standard or best practice to just denote time in a swagger spec that works well with the Jackson deserialisers?
Is denoting time in milliseconds/seconds and using type string in swagger an acceptable approach?
Depending on what you're trying to represent, this may or may not be a good idea.
If you want to represent a specific timestamp, then it's probably much safer to include the date.
If the date really isn't important (eg. you want to indicate that an event takes place at 14:00 every day), then I don't believe swagger has a built in format for that. However, the swagger format field is open and swagger has support for ECMA 262 regex string patterns.
I have case classes that may be used for representing models that originate from either a database table or API object.
Should I use joda or java.util.date or java.sql.date or?
This is for a playframework app, and I will use these models to display the datetime on the UI side of things where I will convert the date to the current users timezone also.
I'm just really confused.
Agreeing with the Answer by mkurz…
java.time
Both java.util.Date and java.sql.Date, and their related classes, have been supplanted by the java.time framework built into Java 8 and later. See Oracle Tutorial. Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport and further adapted to Android in ThreeTenABP.
Search Stack Overflow to learn more (after reading the Oracle Tutorial linked above). Many examples and discussions have been posted.
Basic concepts
Date-time handling is surprisingly tricky. Leave your intuition at the door.
Strings are not date-time values; they are a representation of date-time values. Focus on using objects, not strings.
You may work with a date-only, a time-only, or a date-time.
Know that offset-from-UTC is just a number of hours/minutes/seconds while a time zone is a superset, adding rules for handling anomalies such as Daylight Saving Time (DST). Use OffsetDateTime for one, and ZonedDateTime for the other.
ISO 8601 standard provides sensible formats when parsing & generating Strings to represent date-time values.
The “Local…” types mean “no specific locality”. These have no meaning, are not points on the timeline, until you specify the context of a specific time zone.
The 3-4 letter abbreviations such as EST or IST you commonly see in the media are not time zones, are not standardized, and are not unique(!). Proper time zone names are continent/region.
Apply a time zone for presentation to the user, but most of your business logic, data storage, and data exchange should be in UTC (the Instant class).
Tips
While programming, forget about your own local time zone. Think in UTC.
Learn to read & write 24-hour clock times.
I would recommend http://www.joda.org/joda-time/quickstart.html
It works really nicely with play's json formatters and comes with a ton of helpers.
You are looking for java.time.ZonedDateTime which was introduced in Java 8 and should be used for representing date and time related information that have a timezone. You can save values like 2016-05-30T00:23:27.070Z with it. There is no need to use a third party library like joda time anymore (maybe in other cases there is, but not in your's)
(Do not use java.util.Date - most of it's methods are deprecated, for good reasons)
As a blogger saied:
「Scala does not have a datetime package, but we can use the ones provided by Java.
Java 8 provides a better data/time API, so 3rd-party libraries like Joda-Time is no longer required.」
Here is the blog:
https://www.hackingnote.com/en/scala/datetime
This will be helpful to you.
In official documentation I can't find any information how to write conditional statements for java.util.Date type fact fields in guided rules. For example how to compare such field to current date, check if it is equal omitting time, or check if it is date before some time from now?
Drools isn't a real-time program and it doesn't have an innate idea of Time or Now. If you need to investigate relations of some fact property w.r.t. some point of time X, you'll have to establish a fact carrying X as its data, and write your rules based on that.
A more or less coarse approximation of a fact representing Now can be made using timers. You can implement a rule that modifies a fact containing a value representing Time (e.g. java.util.Date) every second, or less frequently.
Blending out the time of the day is something you'll have to do using Java or DRL functions. Alternatively, if it is days you are interested in, use some custom class representing days, with some suitable day 1 defined by you.
you can give like
inputDate>=11-Nov-2014
provide your current date to inputDate rule input Fact variable.
I have to delete a few tests I create if the timestamp on these are older than a week.
On making a call to the API I get the created_at time stamps of all the tests in this format :
2014-08-04T04:49:28Z ,
2014-08-04T04:49:22Z ,
etc..
It looks like a DateTime object but is a String actually. So firstly is there a way to convert this to a DateTime object?
I need to compare these against the current time and date and check whether they are older than a week or not. For this I know there are several ways but I wanted to know which one is the shortest and most efficient in scala without importing any java utility. Though Joda would have been helpful but the API response gives me String
Thanks in advance!
Consider Scala wrappers for Joda (e.g GitHub /nscala-time
). It provides a rich API and avoids Java Date non thread-safety and mutability.
See What's the standard way to work with dates and times in Scala? Should I use Java types or there are native Scala alternatives? for further comments/discusison and usage examples.
What is the best way to transfer Dates and Times across. I am using GWT on the client/browser side and .NET C Sharp on the server and I am using JSON as data-interchange format. I am currently storing all the dates and times on the server as .NET DateTime. Now I have noticed, that if I use the GWT DatePicker or DateBox to pick a date and send it to the server as miliseconds (by doing date.getTime()) where the server takes this param as DateTime, I can see an hour offset due to the BST. I have situations where I have to have the date and time in separate boxes on the UI and the time setting along with the correct date is crucial because of scheduling.
The best way to interchange Date and Time values would be to serialize them into culture-independent, UTC based strings like: 2010-09-18T18:37:11. The problem is, Date and Time related operations tend to be implemented incorrectly...
As for your problem, I assume that it pops up during deserialization of JSON time, i.e. .Net treats this time as local (DateTimeKind.Local or DateTimeKind.Unspecified), thus converting it. Not sure how to deal with it, the brute force would be probably sending serialized string like above and deserializing manually like this:
DateTime date = DateTime.Parse(dateString, CultureInfo.InvariantCulture, DateTimeStyles.AssumeUniversal);
I'd recommend using standard such as ISO 8601 to transfer date time info in a string form. At my company, date time information encoded in JSON object is almost always in this format, e.g. "2015-10-12T18:41:11+01:00". This string can be parsed and understood correctly in all clients with different programming languages (Obj-C, Java, C/C++).