We are building a solution to optimize crew, we start working in opta with time window but i don't know the format of time.
What is actually the format of time in optaPlanner (Service time and due start time) and how i can Implement time conversion between java and C#??
It depends on your OptaPlanner implementation of the use case. Normally, you'd use java.time.* classes on the Java/DRL side to accurately deal with timezones etc in your constraints.
As for bridging Java and C#, just connect through a REST service and use the standard ISO format (yyyy-mm-dd hh:mm:ss) in the JSON or XML input/output.
Related
For (non regression) testing purpose, I frequently need to make DB2 LUW return a "fake" current date.
This is of course due to application code that rely on the current date / timestamp , and which will behave differently when run during a different date.
We have the possibility to change the operating system (Linux for instance) date , since the testing environment are isolated and dedicated per tester.
Unfortunately, this doesn't help a lot, since we face at least two problems :
1) Binding programs (Cobol) when the system date goes backward gives errors (tables not found, ...)
2) Functions created after the 'past' system date are also not usable....
For the point 1), we can set the date to present , then bind, then come back to past,
But for point 2), I didn't find a workaround.
Does anybody have experience on this problem ? Any alternatives including free or proprietary software are welcome.
Many years ago, our shop purchased a proprietary utility to assist in testing Year-2000-related program changes.
The software allowed us to specify an arbitrary "current" date and time in our test JCL, using parameters "ALTDATE" and "ALTTIME":
//STEP1 EXEC PGM=MYPGM,ALTDATE=MM/DD/YYYY,ALTTIME=HH.MM
Program calls to system date routines, like COBOL "ACCEPT . . . FROM DATE" or DB2 "CURRENT TIMESTAMP", would then return values based on a "fake" system clock that started with the specified date and time.
I believe the product also supported use of a simulated clock in CICS regions for testing of on-line applications, but I could be mistaken. Unfortunately, management decided to stop renewing the product license some time after Y2K had passed, even though several of us developers found it to be very useful for testing date-sensitive logic.
Although I do not know the name of the product we used, a Google search turns up one called "Simulate 2000" by DTS Software that appears to have identical functionality.
I was replacing internal Serializations in my application from Jil to Bond.
I'm switching simple classes with Ms Bond attributes and everything worked fine until I got one with a DateTime.
I had then a Dictionary KeyNotFound Exception error during Serialization.
I suspect Bond do not support DateTime, is that so?
And if it is, why is not implemented? DateTime is not a basic type but adding a custom converter is not worth it, the speed gain vs protobuf-net is minimal and I don't need generics, just simple fast de/serializer.
I hope I'm missing something, I really want to use Bond, but I need an easy tool too, I cannot risk breaking the application because something basic like a Date or Guid is not supported by default.
I'm writing here after hours of researches and the Young Guide to C# bond does not clearly mention what is and what is not supported.
No, there is no built-in timestamp type in Bond. The built-in types in Bond are documented in the manual for the gbc compiler.
For GUIDs, there's Bond.GUID, which has implicit conversions to/from System.Guid. Note that Bond.GUID lives in bond.bond, so if you want to refer to this from a .bond file, you'll need to use Bond's import functionality and import "bond/core/bond.bond"
There's an example showing how to use DateTime with a custom type alias.
The reason there is no built-in timestamp type in Bond is that there are so many different ways (and standards) for representing timestamps. There's a similar C++ example that shows representing time with a boost::posix_time::ptime, highlighting the various different ways that time is represented.
Our experience has been that projects usually already have a representation for timestamps that they want to use, so, we recommend using a converter so that you can use the representation that's appropriate for your circumstances.
As a side note, my experience has been that DateTimeOffset is a more generally useful type, compared to DateTime.
I am trying to decide on the correct way to deal with internationalization in a wcf web service, specifically pertaining to the Numeric Format and the Date Format. My service will support multiple languages and cultures. My question is how we should handle input and output serialization for the different Date and Number formats.
For Dates, I am thinking I will just expect that they be submitted and returned as UTC. To me this seems reasonable and a developer say in the Netherlands, should be able to deal with this format.
My other concern is with numeric types, specifically decimals. I am using the xsd:decimal data type, which uses the "." character as the decimal separator. I am wondering if this will be a problem for say a Dutch developer where they use the "," instead of the "." as the decimal separator.
I am not returning any translated text, so that is not a concern. I just want to make sure that returning and accepting a standard numeric and date format, is the right thing to do. As I am not an international developer, I am having hard time putting myself in their shoes.
Any help is appreciated.
If possible, I'd make the WCF service work with value types (numerics & date/time) in a culture agnostic manner. Since the XSD standard defines decimal using a period character for the decimal separator, it should be the responsibility of the client software to deserialize it and apply any culture specific formatting. The same should apply for date/time serialization except that time should be UTC as you point out.
is there a way to "force" dojo to show date and time in DateTextBox and TimeTextBox widgets in UTC independently of the SO configuration?
Thanks.
It's a lot more than you want, but you could try requiring dojox.date.timezone and overriding the format to use a particular timezone (not sure offhand whether you could pass in a particular parameter through the widgets or if you'd have to do some monkey patching) That's the more general solution, but I don't know if it's been tested. The timezone code is still experimental.
You could probably fake something also by monkeypatching the method that does the display in the widget to subtract the offset from the time, but that wouldn't be "safe" for daylight savings, etc. , otherwise I think you'd need to go put conditionals in to use UTC accessors in the dojo.date code.
We're using Lucene to develop a free text search box for data delivered to a user, as in the case of an email Inbox. We'd like to allow for the box to handle dates, for instance 5/1/2011. To make things easier, we are limiting the current version of the feature to just two date formats:
mm/dd/yy
mm/dd/yyyy
For our prototype we hacked the query analysis process to attempt to pre-process the query string to look for these two date patterns. This was about 2 years ago, and we were on Lucene 2.4. Im curious to see if there are any tools in Lucene out-of-the-box to accept a DateFormat and return a TokenStream with any identified dates. Looking through the javadocs for Lucene 2.9, I found the class:
org.apache.lucene.analysis.sinks.DateRecognizerSinkFilter
which seems to do what I need, but it implements a SinkFilter, a concept which doesn't seem to be documented in the Lucene Wiki. Has anyone used this filter before, and if so, what is the most effective way to use it?
There is a bit of sample code (which is, admittedly, over-complicated) in the documentation for TeeSinkTokenFilter. Note that the way the DateRecognizerSinkFilter is designed, it does not store the actual date; it just detects that a token is a date that conforms to the specified format. What I would try is to re-implement the DateRecognizerSinkFilter class to take an array of DateFormat instances, create a new Attribute class called DateAttribute (or some-such) and use the date recognizer subclass to set the parsed date into the DateAttribute if one of its formats matches. That way, you can always test whether you have a valid date by interrogating the DateAttribute, and localize the date formats to one class. Another advantage is that you won't have to handle multiple sinks, thereby simplifying the code from the linked example.