Recently started porting an application from Windows Phone 8 to Windows 8 RT, and faced strange problem: can't find a way to convert DateTime structure to double OLE date.
Earlier, there were methods DateTime.FromOADate and DateTime.ToOADate to do this, but now they are not available.
...
double oaNow = System.DateTime.Now.ToOADate(); //ToOADate undefined
...
What can be wrong?
For whatever reason this was not included in the RT targets. It doesn't do anything particularly special, it it appears it could be portable.
You can probably duplicate the functionality in your own method by looking at the Reference source for the .NET Framework.
Try
double oaNow = System.DateTime.Now.Subtract(new DateTime(1899, 12, 30)).TotalDays;
According to the documentation
An OLE Automation date is implemented as a floating-point number whose integral component is the number of days before or after midnight, 30 December 1899, and whose fractional component represents the time on that day divided by 24. For example, midnight, 31 December 1899 is represented by 1.0; 6 A.M., 1 January 1900 is represented by 2.25; midnight, 29 December 1899 is represented by -1.0; and 6 A.M., 29 December 1899 is represented by -1.25.
Related
I don't know if this is a bug or if I'm using this method incorrectly.
Can someone explain to me why I got a weird value when parsing this date?
This is the minimal script:
void main(){
DateTime zero = DateTime.fromMillisecondsSinceEpoch(0);
print(zero.millisecondsSinceEpoch);
DateTime errorDate2 = DateTime(1969,1,1);
print(errorDate2.millisecondsSinceEpoch);
DateTime errorDate = DateTime(1969,10,2);
print(errorDate.millisecondsSinceEpoch);
}
Based on my sample, the result seems fine when I parse dates bigger than 0 milliseconds since the epoch.
But it gets weird when I parse some date less than 0 milliseconds since the epoch.
From that script, I got this output
0
-31536000000
-7862400000
I parse that output to this website.
In the first and second results, the results are fine, but in the third result, I got a date around 1720.
Can someone explain to me what happens to that function? Did I use it wrong?
What should I do when I want to parse a date less than 0 milliseconds since the epoch?
In a computing context, an epoch is the date and time relative to which a computer's clock and timestamp values are determined. The epoch traditionally corresponds to 0 hours, 0 minutes, and 0 seconds (00:00:00) Coordinated Universal Time (UTC) on a specific date, which varies from system to system. Most versions of Unix, for example, use January 1, 1970 as the epoch date; Windows uses January 1, 1601; Macintosh systems use January 1, 1904, and Digital Equipment Corporation's Virtual Memory System (VMS) uses November 17, 1858.
So here epoch time starts on January 1, 1970, so it will give you a minus value for milliseconds.
You can still parse the date. it will gave just minus value nothing else.
void main() {
DateTime zero = DateTime.fromMillisecondsSinceEpoch(0);
print(zero.millisecondsSinceEpoch);
DateTime errorDate2 = DateTime(1969,1,1);
print(errorDate2.millisecondsSinceEpoch);
DateTime errorDate = DateTime(1969,10,2);
print(errorDate.millisecondsSinceEpoch);
DateTime error3 = DateTime.fromMillisecondsSinceEpoch(errorDate.millisecondsSinceEpoch);
print(error3);
}
Result is
0
-31555800000
-7882200000
1969-10-02 00:00:00.000
It seems that the bug comes from the website that I refer to it.
Thanks! #jamesdlin
I am trying to figure out how to get the number of DNS queries/second for each domain controller using PowerShell Get-DnsServerStatistics. I copied some of the relevant outputs below.
I try to figure out what is the time period of getting 11793847 "TotalQueries" ?
Under section "TimeStatistics," does the field "TimeElapsedSinceLastClearStatisticsBetweenRestart" with value 00:00:28 means 28 seconds? There is another field "TimeElapsedSinceServerStart" has value 34.01:35:21 and I don't understand what it means? maybe 34 days 1 hour 35 min 21 second?
But if there are 28 seconds with total 11793847 DNS queries. i.e. 421208 queries/second is seems not true in our environment. Could you please help me out?
TimeStatistics:
==============
**TimeElapsedSinceLastClearedStatisticsBetweenRestart 00:00:28**
LastClearTime 9/7/2021 9:33:20 PM
ServerStartTime 9/7/2021 9:33:20 PM
TimeElapsedSinceLastClearedStatistics 34.01:35:21
TimeElapsedSinceServerStartBetweenRestart 00:00:28
**TimeElapsedSinceServerStart 34.01:35:21**
Query2Statistics:
================
TypeAll 1917
TKeyNego 0
TypeOther 897431
**TotalQueries 11793847**
Your assumptions about the time formats are correct. The *BetweenRestart times are the offline times of your DNS service. The time you are looking for is
TimeElapsedSinceLastClearedStatistics - TimeElapsedSinceLastClearedStatisticsBetweenRestart
This is the timespan in which your DNS service was actually answering queries (34.01:34:53). I recommend to parse the timespans into TimeSpan objects using [System.TimeSpan]::Parse("34.01:35:21"), for example. Then you can easily subtract the timespans like shown above.
The resulting timespan object offers you the TotalSeconds member attribute, which you can use for your ratio calculation (your ratio is about 4 queries/s).
I tried to do this:
long Plptime = player.getStatistic(Statistic.PLAY_ONE_TICK)*50L; //from ticks to ms(1 tick (20 each sec) by 50 gives aprox the ms)
SimpleDateFormat formatter = new SimpleDateFormat("dd 'days,' HH
'hours and' mm 'minutes'", Locale.getDefault());
Date date = new Date(Plptime);
String result1 = formatter.format(date);
But when it messages the String to the player (minecraft by the way), the hours and days start on 1 while the min start on 0, for example right when someone just joins his playtime will be 01days 01 hours 00 min. Any solutions? Thanks
Java 9 or later
Let’s first declare a couple of helpful constants.
private static final int TICKS_PER_SECOND = 20;
public static final Duration ONE_TICK = Duration.ofSeconds(1).dividedBy(TICKS_PER_SECOND);
Now do:
int ticks = player.getStatistic(Statistic.PLAY_ONE_TICK);
Duration plpTime = ONE_TICK.multipliedBy(ticks);
String result1 = String.format(Locale.ENGLISH, "%02d days %02d hours and %02d minutes",
plpTime.toDays(), plpTime.toHoursPart(), plpTime.toMinutesPart());
System.out.println(result1);
This prints a string like
00 days 17 hours and 08 minutes
Possibly the number of ticks per second (20) is already declared as a constant somewhere in Bukkit, I don’t know. If it is, take that one rather declaring your own.
Java 6, 7 or 8
The toXxxPart methods I used were introduced in Java 9. Without them we need to calculate the individual parts like this:
long days = plpTime.toDays();
plpTime = plpTime.minusDays(days);
long hours = plpTime.toHours();
plpTime = plpTime.minusHours(hours);
long minutes = plpTime.toMinutes();
String result1 = String.format(Locale.ENGLISH, "%02d days %02d hours and %02d minutes",
days, hours, minutes);
The result is the same as above.
Question: How can that work in Java 6 or 7?
The Duration class that I am using is part of java.time, the modern Java date and time API
In Java 8 and later and on newer Android devices (from API level 26, I’m told) java.time comes built-in.
In Java 6 and 7 get the ThreeTen Backport, the backport of the new classes (ThreeTen for JSR 310; see the links at the bottom).
On (older) Android use the Android edition of ThreeTen Backport. It’s called ThreeTenABP. And make sure you import the date and time classes from org.threeten.bp with subpackages.
What went wrong in your code?
Why the hours seem to start at 1 (not 0): It’s your time zone. When you create a Date from your milliseconds, you get the point in time that many milliseconds after the epoch defined as 00:00 UTC on Jan 1, 1970 (which conceptually is quite misleading when the question was when a player joined). If your time zone was 1 hour ahead of UTC in the winter of 1970 (like Central European time, for example), it was already 1 o’clock at the epoch, so the hours count from there.
And since it was January 1, the day is given as 1, of course. Curiously, if you had been in a time zone west of GMT (America/Los_Angeles to give just one example), the date would still have been December 31, 1969 in the first hours after the epoch, so the newly joined player might appear to have been there for 31 days, 16 hours and 00 minutes, for example.
Links
Oracle tutorial: Date Time explaining how to use java.time.
Java Specification Request (JSR) 310, where java.time was first described.
ThreeTen Backport project, the backport of java.timeto Java 6 and 7 (ThreeTen for JSR-310).
ThreeTenABP, Android edition of ThreeTen Backport
Question: How to use ThreeTenABP in Android Project, with a very thorough explanation.
I am using the bootstrap datetime picker.
I have set enabledHours between 8 am to 5 pm and stepping to 30. When i pick the current hour to be 5 pm and increment the minute by one step,the result is a invalid date(5:30 pm). The expected result is not to allow incrementing the time, as it produces invalid date.
Same goes for hours also. E.g. if I pick the time as 4:30 pm and try to increment the hour by one step, it produces 5:30 pm which is not valid according to the enabled hours.
Any workaround for this issue?
I found my answer here: https://stackoverflow.com/a/31950948/495000
Turns out the trick is to use the disabledTimeIntervals option instead of EnabledHours.
Note that disabledTimeIntervals takes an array of arrays - representing a list of disabled ranges.
For example, I needed the following, which disables the times between 12:00 AM to 06:59 AM, and between 6:01 PM and 11:59 PM (technically 12:AM the next day the way it's written...). If you consider the inverse, this means I'm enabling from exactly 7:00 AM to exactly 6:00 PM.
.datetimepicker({
format: 'hh:mm A',
stepping: 15,
disabledTimeIntervals: [
[moment().hour(0).minutes(0), moment().hour(6).minutes(59)],
[moment().hour(18).minutes(1), moment().hour(24).minutes(0)]
]
Due to the limitation of date parsing on BlackBerry I'm trying to roll my own parse/deparse methods, however I seem to be falling foul of an hour's difference somewhere, somehow.
I do this:
long nowLong = System.currentTimeMillis();
String nowString = DateParser.longToString(nowLong);
Date nowDateFromString = DateParser.stringToDate(nowString);
Date nowDateFromLong = DateParser.longToDate(nowLong);
When outputted in order it produces this in console:
[139.46] 1369132556831
[139.46] 21 May 2013 11:35:56 Europe/Dublin
[139.46] Tue May 21 12:35:56 Europe/Dublin 2013
[139.46] Tue May 21 11:35:56 Europe/Dublin 2013
My simulator's time is set to 11:35 so the third statement - DateParser.stringToDate() - seems to be failing somewhere.
Here is my implementation:
public static Date stringToDate(String date) {
long l = HttpDateParser.parse(date);
Date d = new Date(l);
return d;
}
As my nowString includes the time zone I'd expect HttpDateParser.parse() to take this in to account but it seems not to be.
How can I correct this?
HttpDateParser.parse() is documented to handle "GMT" or a "TZD" which I assume to be a "time zone designator". I suspect this is expected to be the (horrible, ambiguous) abbreviation format - so for example, it might be worth trying to parse
21 May 2013 11:35:56 BST
and seeing what you get out. That would at least take you further in terms of diagnosing the behaviour of HttpDateParser. Keeping the time zone's TZDB ID is a better idea in my view, but you may well need to write your own parsing code. You still need to handle local time ambiguity though, where a particular local time occurs twice due to DST transitions.
It's not entirely clear what the input or expected output are in your case - how much control you have over the format. I'd try to use ISO-8601 as far as possible, with a time zone identifer as well if you need one. (If you're only trying to represent an instant in time, I'd use an ISO-8601 representation of the UTC instant, complete with a Z suffix to indicate UTC.)