I am trying to find the duration between two times with the below code:
DateTimeFormatter formatter = DateTimeFormat.forPattern("HH:mm");
System.out.println(airTime1);
System.out.println(startTime1);
Minutes difference = ((Minutes.minutesBetween(startTime1,airTime1)));
String differenceS = String.valueOf(difference);
System.out.println(differenceS);
LocalTime remaining1 = formatter.parseLocalTime(differenceS);
System.out.println(remaining1);
airTime1 & startTime1 are both localTime variables. difference should contain the duration between the two times. differenceS is a String representation of difference, as minutes cannot be converted to String.
When I enter times into the variables such as 12:00 & 13:00, the variables are recorded as: 12:00:00.000 & 13:00:00.000, but differenceS received a value of PT-60M, which obviously throws an error. Does anyone know why the minutes difference line could be calculating this value?
Thanks in advance!
The Minutes class of jodatime overwrites the toString() method in a way that returns a String in ISO8601 duration format as mentioned in the JavaDoc. This is exactly what your PT-60M represents. A duration of -60 minutes.
If you just want the raw minutes printed your code could look like this:
DateTimeFormatter formatter = DateTimeFormat.forPattern("HH:mm");
System.out.println(airTime1);
System.out.println(startTime1);
Minutes difference = Minutes.minutesBetween(startTime1,airTime1);
System.out.println(Math.abs(difference.getMinutes()));
Related
Can anyone explain how to convert a Hex TimeDateStamp DWORD value into human readable format?
I'm just curious as to how a value such as 0x62444DB4 is converted into
"Wednesday, 30 March 2022 10:31:48 PM"
I tried googling of course and could not find any explanation. But there are online converters available.
But I'm just interested in converting these values for myself.
Your value is a 32-bit Timestamp.
Your datetime value is a 32-bit Unix Timestamp: The number of seconds since 1/1/1970.
See https://unixtime.org/
In most programming languages you can work with the hexadecimal notation directly.
Implementation should not be done by one person alone, since a lot of engineering goes into it. Leap years, even leap seconds, timezones, daylight savings time, UTC... all these things need to be addressed when working with a timestamp.
I have added my rough calculation below as a demonstration. Definitely use an existing package or library to work with timestamps.
See the JavaScript code below for demonstration.
There I multiply your value by 1000 because JavaScript works in Milliseconds. But otherwise this applies the same to other systems.
let timestamp = 0x62444DB4;
let dateTime = new Date(timestamp * 1000);
console.log('Timestamp in seconds:', timestamp);
console.log('Human-Readable:', dateTime.toDateString() + ' ' + dateTime.toTimeString());
// Rough output, just for the time.
// Year month and day get really messy with timezones, leap years, etc.
let hours = Math.floor(timestamp/3600) % 24;
let minutes = Math.floor(timestamp/60) % 60;
let seconds = Math.floor(timestamp) % 60;
console.log('Using our own time calculation:', hours + ':' + minutes + ':' + seconds);
How can I speed up String to DateTime conversion in Julia? It takes long and allocates a lot of memory in the process?
When you convert a column or vector of strings, define the string format in a separate variable and then pass this variable as a second variable in the function Dates.DateTime.
Assuming, your strings are in a DataFrame column df.Date, then
replace:
df.DateTime = Dates.DateTime.(df.Date , "yyy-mm-dd HH:MM:SS")
with:
myFormat = Dates.DateFormat("yyy-mm-dd HH:MM:SS")
df.DateTime = Dates.DateTime.(df.Date , myFormat)
This speeds up conversion noticeably (in my case by factor 20 for a 30k element vector).
Thanks to user BioTurboNick on discourse.julialang for figuring this out. The reason is in the documentation. Essentially in the former case, julia creates a DateFormat object for each individual conversion, drastically increasing memory allocation.
DateTime(dt::AbstractString, format::AbstractString; locale="english") -> DateTime
Construct a DateTime by parsing the dt date time string following the pattern given in the format string (see
DateFormat for syntax).
This method creates a DateFormat object each time it is called. If you are parsing many date time strings of the
same format, consider creating a DateFormat object once and using that as the second argument instead.```
I have a TimeSpan that I want to round before adding it to my file.
Sometimes its ok like this: 12:03:55 but sometimes it is like this: 04:12:32.96472749
It should not look like this just give me the seconds so I thought of rounding it up or down it doesnt even matter.
I tried this: ([Math]::Round($result)) => Where $result is the timespan but it is saying that the method is overloaded even though I saw it on StackOverflow like this...
also this does not work either: ([Math]::Round($result,2))
Maybe someone can help me because I think there is a special way to round TimeSpans and not normal decimals.
Edit:
I just checked out String Formatting like this:
$formattedTime = "{0:hh\:mm\:ss}" -f ([TimeSpan] $result)
It looks good but I need to add Days in front if the date goes over 24Hours .. so something like 'dd' maybe?
Ty Faded~
You cannot format a TimeSpan object as if it were a DateTime object.
For that, you need to put together your own format string and use the individual properties you need:
Without days:
$ts = [timespan]::new(0,12,3,55,964.72749)
('{0} {1:D2}:{2:D2}:{3:D2}' -f $ts.Days, $ts.Hours, $ts.Minutes, $ts.Seconds).TrimStart("0 ")
# returns 12:03:55
With days (same format string)
$ts = [timespan]::new(11,12,3,55,964.72749)
('{0} {1:D2}:{2:D2}:{3:D2}' -f $ts.Days, $ts.Hours, $ts.Minutes, $ts.Seconds).TrimStart("0 ")
# returns 11 12:03:55
The time properties of a TimeSpan object are ReadOnly, so you cannot set the Milliseconds to 0 unfortunately.
If you do want to get a 'rounded' TimeSpan object where the Milliseconds are stripped off, you can do this:
$ts = [timespan]::new(0,12,3,55,964.72749)
# create a new TimeSpan object from the properties, leaving out the MilliSeconds
$ts = [timespan]::new($ts.Days, $ts.Hours, $ts.Minutes, $ts.Seconds)
I have used to LocalTime provided by Java 8 for formatting the time from 1-24 format to 1-12 format in the following code.
String localTime = LocalTime.parse("08:59:00", DateTimeFormatter.ofPattern("HH:mm:ss"))
.format(DateTimeFormatter.ofPattern("hh:mm:ss a"));
And now with the following code, I have got 1-12 hours format
LocalTime localTime1 = LocalTime.parse(localTime, DateTimeFormatter.ofPattern("hh:mm:ss a"));
My question is "is there any API methods provided by LocalTime" to get ante or post from the given time. Or how to get with clean APIs, instead of manipulating the strings with slice and cut.
I am not sure about the elegance of this, but if you want to get a boolean representing whether it is AM or PM, you could do:
boolean isPM = localTime.getHour() >= 12;
This variable isPM will be false if the time is AM and true for PM.
is there any API methods provided by LocalTime
The method is get. We need to use it in conjunction with the ChronoField.AMPM_OF_DAY enum constant. It encodes ante meridiem into 0 and post meridiem into 1.
int amPmOf1159 = LocalTime.of(11, 59).get(ChronoField.AMPM_OF_DAY);
System.out.println(amPmOf1159);
int amPmOf1200 = LocalTime.of(12, 0).get(ChronoField.AMPM_OF_DAY);
System.out.println(amPmOf1200);
Output is:
0
1
Suppose I have an ISO 8601 duration, expressed as "P1M". Phrased colloquially, this means "one month." Is there a standard rule for converting this into a number of seconds, assuming the start date is not known?
For 30-day months, it might be 2,592,000.
For 31-day months, it might be 2,678,400.
In February, it might be 2,419,200 or it might be 2,505,600.
My gut says there's no way to resolve "one month" to an exact number of seconds without knowing context, and where those seconds are laid out on the calendar. But are there standard rules/conventions to calculate these durations in an abstract way?
From ISO 8601 documentation that I found (page 6 - http://xml.coverpages.org/ISO-FDIS-8601.pdf), it seems you are correct in that the number of seconds in a month cannot definitively be determined. However it does note that "In certain applications a month is regarded as a unit of time of 30 days", so depending on your application this may be a valid approach.
The distinction between "Calendar Time" (Years, Months, etc) and "Absolute Time" (Hours, Minutes, Seconds, etc) is sometimes an important one. As an example, some people might complain about having 13 mortgage payments some years if they paid every 30 days as opposed to every month.
You are right, an ISO 8601 duration is dependent of the context.
A duration is a period/an interval of time between two dates.
Example :
2020-01-01/2020-02-01 = P1M = P31D
2020-02-01/2020-03-01 = P1M = P29D
2019-02-01/2019-03-01 = P1M = P28D
If you want a fixed duration indepedent of the context, use the day notation P30D, P60D, P90D... instead.
The same applies for years :
2019-01-01/2020-01-01 = P1Y = P12M = P365D
2020-01-01/2021-01-01 = P1Y = P12M = P366D
If you can't have context information about a duration, for example P1M retrieved from database or given by user input, use by default today's context.
//What is a duration of one month in seconds ?
P1M = ? (no context)
//Use default context
Today = 2020-03-31
2020-03-31/P1M = 2020-03-31/2020-04-30
=> P1M = P30D
//A month contains 2 592 000 seconds