[wish] Date Operation

Hi friends,

I think it would be useful if we can add/subtract dates in gh . My original thinks about this as follow:Hoping for your words.

Attachments:

date operation.jpg, 230 KB

Replies to This Discussion

Permalink Reply by David Rutten on January 27, 2016 at 6:07am

It's difficult to find a consistent behaviour for it though. Time - Time should result in a Duration (GH doesn't have a duration data type, though I agree it does need one). Date - Date should result in a Duration. Time + Time might conceivably result in another Time (6am + 8am = 2pm), but Date + Date makes no sense to me. 2016/1/5 + 2015/11/16 = what? Clearly not 4031/12/21... but I don't know what it should be.

You can combine dates and time using the special [Combine Date & Time] component, and I agree that the Addition component should have handled that case as well, but it doesn't now.

I think the main problem (both the cause of your pain and the thing that prevents good solutions) is that dates and times are awkwardly supported by .NET. There's a DateTime struct which is very efficient but which does not allow for a clear separation into pure dates and pure times. To remedy this I added some logic (one tick past midnight means the DateTime is meant to be a pure date, two ticks past the second means the DateTime is meant to be a pure time) but it's very much a hack.

I wonder if it makes more sense to design custom date, time and duration types for GH2, that would allow for a more robust mathematical approach.

Permalink Reply by Joseph Oster on January 27, 2016 at 6:22am

Why not follow the standard 'DateTime' models in PHP, Java and JavaScript?

PHP: http://php.net/manual/en/class.datetime.php

JavaScript: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/G...

Would be nice to have benchmark abilities as standard GH features, as is commonly done in PHP, JSP, JavaScript, etc.

var start = Date.now();
// the event to time goes here:
doSomethingForALongTime();
var end = Date.now();
var elapsed = end - start; // elapsed time in milliseconds

Permalink Reply by David Rutten on January 27, 2016 at 6:46am

You have to be careful with Date.Now (btw. you should always consider using Date.UtcNow when programming, Date.Now is only for when the resulting date is supposed to be presented to humans), it has a pretty bad accuracy. The Diagnostics.StopWatch class is better at accurately measuring short intervals.

There's a good article on Eric Lippert's old MSDN blog about the precision and accuracy of measuring time. Basically, just because DateTime has a high precision, that doesn't mean that you get accurate values when the ask the OS what time it is. Think of it as a referee using a stopwatch to time athletes running laps. It doesn't matter if the stopwatch supports centi, milli, micro, or nanoseconds, the thumb of the referee is only accurate to within a quarter of a second.

I'm not familiar with how Java approaches dates and times, I'll have a look at your links but from a first casual glance it doesn't seem like they are any better than (or indeed very different from) the .NET approach.

Permalink Reply by David Rutten on January 27, 2016 at 6:55am

The basic problem I ran into with GH1 is that there's basically three different things you might want to represent that involve dates and times:

Just a date (September 4th, 2010)
Just a time (11:35)
Both a date and a time (11:35 on September 4th, 2010)

The .NET DateTime structure only really supports the third. It counts the number of 'ticks' (1 tick = 100 nanoseconds) since midnight on January the first in the year 1. It does not support any moment in history before the year 1, it does not support any date beyond the year 9999 (ok, not a big drawback that one) it does not support calendars other than Gregorian, it does not support time zones, it does not allow you to just specify a time only and leave the date blank or vice versa.

Some of these shortcomings can be hacked onto the structure, basically by hijacking the tick count and assigning special meaning to certain small tick offsets, but there's always trade-offs with such an approach.

Permalink Reply by Joseph Oster on January 27, 2016 at 6:59am

Here is an overview of Java time/date:

https://docs.oracle.com/javase/tutorial/datetime/iso/overview.html

I've been using various versions of 'Date.Now' for good benchmarks for DECADES, from UCSD Pascal through JSP, PHP and JavaScript.

Permalink Reply by David Rutten on January 27, 2016 at 8:21am

How often the OS updates the system clock depends on a whole bunch of variables. What OS? What version? What bit-depth? What hard-ware? Code measuring performance way well behave differently on different computers, even if the actual time being measured is roughly the same. Of course the longer the measured interval the more accurate (relatively) DateTime.Now becomes. However if you only want to measure the cumulative effect of a small portion of a for loop, calling DateTime.Now in quick succession may well mean that the OS clock has not been updated in the mean time, giving you a result of zero. Or maybe the clock was updated in the mean time but the update interval is so large that you measure a far longer interval than actually happened.

If you're using .NET, then you should always use System.Diagnostics.StopWatch for performance tracking. It's as accurate as possible given the current environment and it's low-overhead.

Permalink Reply by Alpha222 on January 27, 2016 at 8:02pm

"var elapsed = end - start"

Hi Joseph, the final result returns interger?

Permalink Reply by Joseph Oster on January 28, 2016 at 5:40am

Yes. As it says in the JavaScript docs:

Creates a JavaScript Date instance that represents a single moment in time. Date objects are based on a time value that is the number of milliseconds since 1 January, 1970 UTC.

This common standard applies to Java and PHP as well. Date and time are treated as a single integer type (milliseconds) which allows "Date + Hours = Date" and many other conveniences.

As to benchmarks, I'm aware of the OS clock issues (back in the day, the first IBM PC running UCSD Pascal had a minimum interval of 18 milliseconds) but have always found that by counting enough loops so that the elapsed time is considerably greater, good benchmarks are easy and accurate.

Permalink Reply by Fred Becquelin on January 27, 2016 at 11:19am