Did like below,
LocalDateTime currentUTCTime = LocalDateTime.now(ZoneId.of("UTC"));
String reqPattern = currentUTCTime.format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss:SSS"));
System.out.println("Required pattern: " + reqPattern);
GregorianCalendar calendar = GregorianCalendar.from(currentUTCTime.atZone(ZoneId.systemDefault()));
XMLGregorianCalendar xcal = DatatypeFactory.newInstance().newXMLGregorianCalendar(calendar);
System.out.println("But Showing As :" + xcal);
I want the output as 2015-06-18 11:59:15:135, but when i set the xcal to
a XML tag which takes XMLGregorianCalender, it shows like 2015-06-18T11:59:15.135+05:30.
How can i remove the +05:30 portion?
Use this code:
LocalDateTime currentUTCTime = LocalDateTime.now(); // using system timezone
String iso = currentUTCTime.toString();
if (currentUTCTime.getSecond() == 0 && currentUTCTime.getNano() == 0) {
iso += ":00"; // necessary hack because the second part is not optional in XML
}
XMLGregorianCalendar xml =
DatatypeFactory.newInstance().newXMLGregorianCalendar(iso);
Explanation:
The code makes use of the given factory method expecting a lexicographical representation of a local timestamp in ISO-8601-format. And since a LocalDateTime does not refer to any timezone, its output via toString() cannot contain a timezone offset. Result: XMLGregorianCalendar considers the timezone offset as "not set".
Correction:
The original code did not especially bother about the ISO-variant of formatted output of currentUTCTime.toString(). However, the java.time-API produces an output without seconds or nanoseconds if those parts are equal to zero. This is perfectly legal in ISO, but the W3C-consortium has made the second part non-optional. And the class XMLGregorianCalendar closely follows this deviating spec. Therefore the shown hack above using simple string concatenation in this special edge case. Thanks a lot to #Dave's comment. By the way, using currentUTCTime.format(DateTimeFormatter.ISO_DATE_TIME) as suggested in this comment is also possible (instead of the shown hack).
Related
I have the following datetime helper method that converts a UTC-zoned Java 8 Date into a datetime string:
public static String dateTimeString(Date date) {
return date.toInstant().atZone(ZoneId.of("UTC")).toLocalDateTime().toString();
}
The desired result is to always have the resultant String be formatted as:
YYYY-MM-dd'T'HH:mm:ss'Z'
Problem is, Java 8 LocalTime#toString() intentionally strips off time components that are zero. So for instance if I have a Date instance that represents June 8, 2018 at 12:35:00 UTC. Then the output of this method above is: 2018-06-08'T'12:35'Z'. Whereas I want it to contain any zeroed-out second/minute/hour components (e.g. 2018-06-08'T'12:35:00'Z').
Any ideas?
private static DateTimeFormatter formatter = DateTimeFormatter.ofPattern("uuuu-MM-dd'T'HH:mm:ssX");
public static String dateTimeString(Date date) {
return date.toInstant().atOffset(ZoneOffset.UTC).format(formatter);
}
Just use a fixed format pattern string to get your desired format. Let’s try it:
System.out.println(dateTimeString(new Date(0)));
System.out.println(dateTimeString(new Date(1_524_560_255_555L)));
This prints:
1970-01-01T00:00:00Z
2018-04-24T08:57:35Z
In the first example hours, minutes and seconds are printed even if they are 0.
In the second example milliseoncds are omitted even when they are non-zero (you see that the milliseconds value I specified ends in 555).
All of this said, the output conforms to the ISO 8601 format no matter if you have 2018-06-08T12:35Z, 2018-06-08T12:35:00Z or even 2018-06-08T12:35:00.000000000Z. So you may want to check once more whether leaving out the second works for your purpose before you take the trouble of defining your own formatter.
Link: Wikipedia article: ISO 8601
I don't see why you portray the default output to have its letters enclosed in single quotes when Java's actual output instead looks like 2018-06-08T12:35Z, but anyway, here's the code that produces it as desired, with no omissions:
final LocalDateTime ldt = LocalDateTime.of(2018, 6, 8, 12, 35, 0);
final ZonedDateTime zdt = ZonedDateTime.of(ldt, ZoneId.of("Z"));
final DateTimeFormatter dtf = DateTimeFormatter.ofPattern("yyyy-MM-dd'''T'''HH:mm:ss''X''", Locale.US);
System.err.println(dtf.format(zdt));
Output:
2018-06-08'T'12:35:00'Z'
Personally, I'd probably prefer a format like this, containing the millis, giving time zone information not requiring additional knowledge from the user, and not having imho superfluous characters:
FORMAT: "yyyy-MM-dd HH:mm:ss'.'SSS Z"
OUTPUT: 2018-06-08 12:35:12.345 +0200
It appears that there is no out of the box solution. The simplest way would be to write your own class that extends DateTimeFormatter and override method public String format(TemporalAccessor temporal) where you would call the original method and then if needed modify the output String. See the flags 'Z' for formatter. If that flag is present then you will need to modify the original output.
I have a String representing a date (with or without time) like 13/12/2017 or 13/12/2017 15:39:51
So i'm trying to use java 8 DateTimeFormatter with optional part.
That code works
LocalDateTime localDateTime = LocalDateTime.parse("13/12/2017 15:39:51",DateTimeFormatter.ofPattern("dd/MM/yyyy[ HH:mm:ss]"));
System.out.println(localDateTime.format(DateTimeFormatter.ofPattern("dd/MM/yyyy")));
System.out.println(localDateTime.format(DateTimeFormatter.ofPattern("HH:mm:ss")));
13/12/2017
15:39:51
But I don't understand why that one does not
LocalDateTime localDateTime = LocalDateTime.parse("13/12/2017",DateTimeFormatter.ofPattern("dd/MM/yyyy[ HH:mm:ss]"));
giving me
Exception in thread "main" java.time.format.DateTimeParseException: Text '13/12/2017' could not be parsed: Unable to obtain LocalDateTime from TemporalAccessor: {},ISO resolved to 2017-12-13 of type java.time.format.Parsed
at java.time.format.DateTimeFormatter.createError(DateTimeFormatter.java:1920)
at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1855)
at java.time.LocalDateTime.parse(LocalDateTime.java:492)
...
And even with
LocalDateTime localDateTime = LocalDateTime.parse("13/12/2017",DateTimeFormatter.ofPattern("dd/MM/yyyy"));
it does not work with the same exception.
Use parseBest
When you use an optional component, you should parse using parseBest. Your application may be working using only parse, but then it's only by luck (because you're only parsing full inputs, not partial ones). With parseBest, you can properly handle various TemporalAccessor, which is the whole reason to use optional.
The decision of which TemporalAccessor is returned is rather simple: parseBest will try to match each TemporalQuery in order of argument. When any matches, the method returns that one. So make sure to go from most precise to less precise. Also, if none were matched, an exception will be thrown.
LocalDateTime dateTime;
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("dd/MM/yyyy[ HH:mm:ss]");
TemporalAccessor temporalAccessor = formatter.parseBest("13/12/2017", LocalDateTime::from, LocalDate::from);
if (temporalAccessor instanceof LocalDateTime) {
dateTime = (LocalDateTime)temporalAccessor;
} else {
dateTime = ((LocalDate)temporalAccessor).atStartOfDay();
}
I've seen that you can use an ".isValid()" function to check that a given string is in a date format:
moment('2007-05-05', 'YYYY-MM-DD', true).isValid()
But is there a way to confirm that the format is correct? For example:
'YYYY-MM-DD' should return true, but
'YYYY-MM-DDsadsadl' should return false since the characters at the end of the string aren't valid DateTime chars.
We're working on a tool that allows a user to input an existing date format, and then a second input to enter the desired format, but we need validation to ensure the string can properly parse and convert, but they aren't entering a specific date.
The application must accept any and all possible date formats.
Use the following function to validate your format.
validFormat = function(inputFormat){
var validation = moment(moment('2017-06-17').format(inputFormat), inputFormat).inspect();
if(validation.indexOf('invalid') < 0)
return true;
else
return false;
}
Do spend some time to understand this. This simply does a reverse verification using inspect(). The date 2017-06-17 can be replaced by any valid date.
This Moment Js Docs will help you identify the valid formats.
Just make a call to this function as
validFormat('YYYY MM DD')
const getIsValid = inputFormat => moment(moment().format(inputFormat), inputFormat).isValid()
Explanation:
moment().format(inputFormat) - Create a date string from the current time from that format
This is then wrapped with moment() to make that string a moment date object, defining the format to parse it with. Finally we call the isValid() property on that moment date object. This ensures we are able to both create and parse a moment with our custom format.
Given this ApiController:
public string TestString() {
return "The value is: " + 1.23;
}
public double TestDouble() {
return 1.23;
}
With the browser's language set to "fr-FR", the following happens:
/apiController/TestString yields
<string xmlns="http://schemas.microsoft.com/2003/10/Serialization/">The value is: 1,23</string>
/apiController/TestDouble yields
<double xmlns="http://schemas.microsoft.com/2003/10/Serialization/">1.23</double>
I would expect TestDouble() to yield 1,23 in the XML. Can anyone explain why this isn't the case and, more importantly, how to make it so that it does?
It is because the conversion from double to string happens at different stage for each API. For the TestString API, double.ToString() is used to convert the number to a string using CurrentCulture of the current thread and it happens when the TestString method is called. Meanwhile, the double number which is returned by TestDouble is serialized to string during the serialization step which uses GlobalConfiguration.Configuration.Formatters.JsonFormatter.SerializerSettings.Culture.
In my opinion, both should use InvariantCulture. On the consumer side, the values will be parsed and be formatted with the correct culture.
Update: this is only used for JsonFormatter. XmlFormatter doesn't have such a setting.
Update 2:
It seems (decimal) numbers need special converter to make it culture-aware:
Handling decimal values in Newtonsoft.Json
Btw, if you want o change data format per action/request, you can try the last piece of code of the following link: http://tostring.it/2012/07/18/customize-json-result-in-web-api/
I am using Velocity 1.7 to format string and I had some trouble with default values. Velocity by itself has no special syntax for case when value is not set and we want to use some another, default value.
By the means of Velocity it looks like:
#if(!${name})Default John#else${name}#end
which is unconveniant for my case.
After googling I've found DisplayTool, according to documentation it will look like:
$display.alt($name,"Default John")
So I added maven dependency but not sure how to add DisplayTool to my method and it is hard to found instructions for this.
Maybe somebody can help with advice or give useful links?..
My method:
public String testVelocity(String url) throws Exception{
Velocity.init();
VelocityContext context = getVelocityContext();//gets simple VelocityContext object
Writer out = new StringWriter();
Velocity.evaluate(context, out, "testing", url);
logger.info("got first results "+out);
return out.toString();
}
When I send
String url = "http://www.test.com?withDefault=$display.alt(\"not null\",\"exampleDefaults\")&truncate=$display.truncate(\"This is a long string.\", 10)";
String result = testVelocity(url);
I get "http://www.test.com?withDefault=$display.alt(\"not null\",\"exampleDefaults\")&truncate=$display.truncate(\"This is a long string.\", 10)" without changes, but should get
"http://www.test.com?withDefault=not null&truncate=This is...
Please tell me what I am missing. Thanks.
The construction of the URL occurs in your Java code, before you invoke Velocity, so Velocity isn't going to evaluate $display.alt(\"not null\",\"exampleDefaults\"). That syntax will be valid only in a Velocity template (which typically have .vm extensions).
In the Java code, there's no need to use the $ notation, you can just call the DisplayTool methods directly. I've not worked with DisplayTool before, but it's probably something like this:
DisplayTool display = new DisplayTool();
String withDefault = display.alt("not null","exampleDefaults");
String truncate = display.truncate("This is a long string.", 10);
String url = "http://www.test.com?"
+ withDefault=" + withDefault
+ "&truncate=" + truncate;
It might be better, though, to call your DisplayTool methods directly from the Velocity template. That's what is shown in the example usage.