I got the time values from the SBT SDK as a string in this format
"2013-07-17T14:44:25.177Z"
I get a Java Date object with this code
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
Date date = dateFormat.parse("2013-07-17T14:44:25.177Z");
But the last part of the string ".177Z" should be a time zone value !?!?!
Do any body know how parse the time zone or the complete date with the time zone in Java?
Thx
Andreas
But the last part of the string ".177Z" should be a time zone value !?!?!
No, I think the .177 is the milliseconds part, and Z is a UTC-offset of 0. (It's not really a time zone, but that's a different matter.)
I suspect you want:
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSX");
(Where X is an ISO-8601 time zone specifier, including Z for UTC.)
Note that X was only introduced in Java 7 - if you're using Java 6 or earlier, you may need to do a bit more work.
You might want to use
javax.xml.bind.DatatypeConverter.parseTime(String)
since the dates found in the atom returned by the IBM Connections API conform to the definition from http://www.w3.org/TR/xmlschema-2/, which can be parsed into a Java Calendar Object by said method. This also accounts for the time zone specifier.
Related
Inside my Docker-Container, which has the timezone Etc/UTC, I need to convert a Date-String which represents a Date in Europe/Berlin-timezone into a UTC timestamp.
So lets say the Europe/Berlin-Date is 2022-04-20T00:00:00.
Now the UTC-Timestamp should be equivalent to 2022-04-19T22:00:00.
But when I do
console.log(new Date("2022-04-20").getTime())
I get 1650412800000 which is equivalent to 2022-04-20T02:00:00 in Europe/Berlin-timezone.
How would I do this?
Edit:
I tried various libs, but still cant get that managed
const { DateTime } = require("luxon")
var f = DateTime.fromISO("2022-04-20").setZone('Europe/Berlin').toUTC()
console.log(f)
also the equivalent stamp in f is 2022-04-20T02:00:00 :/
I need to convert a Date-String which represents a Date in Europe/Berlin-timezone into a UTC timestamp.
Fundamentally, a date-only value cannot be converted into a timestamp, unless you arbitrarily associate a time with that date. It sounds like you meant to use midnight local time (00:00+02:00) but instead you are seeing midnight UTC (00:00Z).
This is due to how you are constructing the Date object. You specify new Date("2022-04-20"), which according to the ECMASCript spec will be treated as midnight UTC. The spec says:
... When the UTC offset representation is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.
Yes, this is inconsistent with ISO 8601, and that has been discussed ad nauseum.
To solve this problem, append T00:00 to your input string, so that you are specifically asking for local time. In other words, new Date("2022-04-20T00:00").
That said, if you need it to not be "local time" but exactly Europe/Berlin, then yes - you'll need to use a library. In luxon, it's like this:
DateTime.fromISO('2022-04-20T00:00', {zone: 'Europe/Berlin'}).toUTC()
I am getting the strings like 1604341549 and want to convert them to normal date format like
12 feb 2012 4:00. Here is my implementation
SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMddHHmmss");
try {
Date d = sdf.parse(date);
sdf.applyPattern("dd MMM yyyy hh:mm");
holder.v.setText(sdf.format(d));
} catch (ParseException ex) {
Log.e("Exception", ex.getLocalizedMessage());
}
I have checked the logs and it is showing the dates as String before the try block but it is not implementing in the try block instead it is giving an error " Unparseable date: "1604341549" ".
Looks like your date is a long that encodes timestamp in seconds so you don't need to parse a String, instead you should simply build a Date object using Date(long date) constructor. don't forget to convert seconds to milliseconds by multiplying it by 1000
java.time through desugaring
Consider using java.time, the modern Java date and time API, for your date and time work. Let’s first declare two formatters, one for your input and one for your desired output.
/** For parsing seconds since the epoch */
private static final DateTimeFormatter unixTimestampFormatter
= new DateTimeFormatterBuilder()
.appendValue(ChronoField.INSTANT_SECONDS)
.toFormatter();
/** For formatting into normal date and time */
private static final DateTimeFormatter normalFormatter
= DateTimeFormatter.ofLocalizedDateTime(FormatStyle.MEDIUM)
.withLocale(Locale.UK);
Now the conversion goes like this:
String inputStr = "1604341549";
Instant inst = unixTimestampFormatter.parse(inputStr, Instant.FROM);
String normalDateTimeStr = inst.atZone(ZoneId.systemDefault())
.format(normalFormatter);
System.out.println(normalDateTimeStr);
Output is:
02-Nov-2020 19:25:49
I am convinced that Shamm is correct in the other answer: your input strings contain so-called Unix timestamps, that is, counts of seconds since the Unix epoch on Jan 1, 1970 at 00:00 UTC. With java.time we can build a formatter that parses such.
For giving “normal” output I am using Java’s built-in date and time format. In this case for UK locale, but you should use your users’ locale for most content users.
What went wrong in your code?
First, you were trying to parse the input string as containing year, month, date, hour, etc., which it didn’t. So you were lucky to get an exception so you got aware that it’s wrong (SimpleDateFormat very often does not give that, leaving you believing that everything is fine when it isn’t).
SimpleDateFormat parsed 1604 as year, 34 as month, 15 as day of month and 49 as hour of day. It then objected because there weren’t any digits left for the minutes (and seconds).
Question: Doesn’t java.time require Android API level 26?
java.time works nicely on both older and newer Android devices. It just requires at least Java 6.
In Java 8 and later and on newer Android devices (from API level 26) the modern API comes built-in.
In non-Android Java 6 and 7 get the ThreeTen Backport, the backport of the modern classes (ThreeTen for JSR 310; see the links at the bottom).
On older Android either use desugaring or the Android edition of ThreeTen Backport. It’s called ThreeTenABP. In the latter case make sure you import the date and time classes from org.threeten.bp with subpackages.
Links
Oracle tutorial: Date Time explaining how to use java.time.
Unix time
Java Specification Request (JSR) 310, where java.time was first described.
ThreeTen Backport project, the backport of java.time to Java 6 and 7 (ThreeTen for JSR-310).
Java 8+ APIs available through desugaring
ThreeTenABP, Android edition of ThreeTen Backport
Question: How to use ThreeTenABP in Android Project, with a very thorough explanation.
I am Using Google APis .net client library to read calendar events.
I have following line of code
newRow["Start"] = pEventItem.Start.DateTime.HasValue ?
Convert.ToDateTime(pEventItem.Start.DateTime) : Convert.ToDateTime(pEventItem.Start.Date);
Where PEventItem is of type Google.Apis.Calendar.v3.Data.Event and NewRow[...] is of type DataRow. The Value of pEventItem.Start.Date is "2019-06-24" (as seen in debug window)
The above line of code works perfect, But fails when UI language / Culture is set to Arabic (SaudiArabia) The same Convert.ToDateTime throws error "String was not recognized as a valid DateTime".
btw, How i am changing the UI language is as below for your information.
Thread.CurrentThread.CurrentCulture = System.Globalization.CultureInfo.GetCultureInfo(ChangeLanguageTo);
Thread.CurrentThread.CurrentUICulture = System.Globalization.CultureInfo.GetCultureInfo(ChangeLanguageTo);
I tried to set 2nd parameter of the Convert.ToDateTime function in an hope that it will convert date correctly...
CultureInfo enUsCulture = new CultureInfo("en-us");
newRow["Start"] = pEventItem.Start.DateTime.HasValue ? Convert.ToDateTime(pEventItem.Start.DateTime, enUsCulture) : Convert.ToDateTime(pEventItem.Start.Date, enUsCulture);
Well Now it does not throw exception, but the returned date is incorrect. value retuned is {21/10/40 12:00:00 ص}
while The actual date pEventItem.Start.Date is "2019-06-24"
I also tried invariant culture also, but result is same, converted date is wrong. What could be the issue?
Regards
There are a few things going on here.
Firstly, if you use EventDateTime.DateTime (e.g. via pEventItem.Start.DateTime) you don't need to call Convert.ToDateTime, because that's already a DateTime?... you can just take the Value property to get a DateTime from a DateTime?. However, I should warn that that can perform time zone conversions that you may not want. (We can't fix the library to avoid those, as it would be a breaking change.) Instead, you may want to parse EventDateTime.DateTimeRaw, which is the original string value returned by the API.
When parsing, I'd suggest using the invariant culture using CultureInfo.InvariantCulture (instead of creating an en-US culture), and parse using DateTime.ParseExact, specifying the format you expect based on whether you're parsing a date or a full date/time.
In terms of "the returned date is incorrect" - I believe that's really just the formatted value that's using the default culture, including the calendar system. We can see that at play in the code below, which constructs the DateTime directly (so can't be affected by any text parsing etc). When formatted using the invariant culture, it shows as 2019-06-24, but when formatted with ar-SA, it shows as "1440-10-21" due to the default calendar system for that culture being System.Globalization.UmAlQuraCalendar:
// Note: when a calendar system is not specified,
// it's implicitly Gregorian.
DateTime date = new DateTime(2019, 6, 24);
Console.WriteLine(date.ToString("yyyy-MM-dd", CultureInfo.InvariantCulture));
Console.WriteLine(date.ToString("yyyy-MM-dd", new CultureInfo("ar-SA")));
So what you're seeing in the debugger is the correct date - but formatted in a way you weren't expecting.
When date was 2018-03-21 19:40, i tried following code
var date = new Date();
console.log(date);
Output :
2018-03-21T16:40:53.755Z
Server is missing for 3 hours as you see. I fixed it by adding 3 hours but I think it's not a good way. How can i fix this problem with better way ?
I don't think the date is incorrect, if you look closely at the format it is being printed, it has a Z at the end, which means:
A suffix which, when applied to a time, denotes a UTC offset of 00:00;
often spoken "Zulu" from the ICAO phonetic alphabet representation of
the letter "Z".
I guess you are in a place separated by 3 hours from UTC.
Node.js uses this format to print Date objects by default, but you can print your local time using toLocaleString():
console.log(date.toLocaleString());
Your server is most likely in another time zone.
I currently convert dates from variant format to string using the VariantChangeType (or CComVariant::ChangeType). That works well, except when the time portion of the variant value is midnight. In that case, the time is simply omitted from the converted string.
A timestamp of 2015/10/07 03:40:00 is converted to a string just as you would expect: "10/7/2015 03:40:00 AM" (using my regional settings).
But a timetamp of 2015/1007 00:00:00 is converted to this string: "10/7/2015" (no time portion included).
I'm trying to preserve that midnight time, and keep the regional settings in use too. I've looked at _strftime_l() - it does include a time in the converted string, but doesn't appear to use the regional settings, even when one is provided via _get_current_locale().
I'm using C++ on Windows.
Has anyone done this?
OK - I found a way to resolve this. Windows has two API calls that will format the date and time with regional settings: GetDateFormat() and GetTimeFormat(). They each take a SYSTEMTIME structure, an output buffer, and a locale specifier. On return, the output buffer contains the date (or time) converted to a string matching the locale and regional settings in use.
I also found that _strftime_l() will actually use regional settings if you call setlocal(LC_ALL, "") first. I was a bit leery of using that method as it may have side affects I'm not aware of.