Dates...

[Lindon]

@ustk @d-healey - I really wish I had the time - but I dont right now...

[ustk]

@Lindon No worries I have to push a big commit today so I'm adding this one with it ;)
But you'll have to wait for the merging of course

[d.healey]

@ustk Wouldn't it be better to make a separate time class rather than adding it to the Engine class? I'm thinking if we want to add more of the JUCE functions in the future it won't be good to clog up the Engine class.

[ustk]

@d-healey I'm kind of agreeing with you but a new class for 2 functions migh be overkill. And I'm sure some people are using the getSystemTime already so this would break the compatibility and leave only one function in a new time api no?

[ustk]

Although it might be possible to just add a parameter to getSystemTime so it can spit out milliseconds...

[Lindon]

@ustk @d-healey

Well this is my "in HISE" stuff that I wanted for the dates....its a mess right now as its all just exploring - but it seems to function as I wanted:

reg leapYears = [1992,1996,2000,2004,2008,2012,2016,2020,2024,2028,2032]; //add more if you need em

function getYearNumber(aDateString)
{
	reg yr = Math.floor(aDateString.substring(0,4));
	return yr;
};
function getMonthNumber(aDateString)
{
	reg mth = Math.floor(aDateString.substring(5,7));
	return mth;
};
function getDayNumber(aDateString)
{
	reg day = Math.floor(aDateString.substring(8,11));
	return day;
};

function getDayOfDate(aDateString)
{
	reg leap = 0;
	reg monthAmounts = [31,28,31,30,31,30,31,31,30,31,30,31];
	reg dayCount = getDayNumber(aDateString);
	reg mnth = getMonthNumber(aDateString);
	reg sumDays;
	if(leapYears.indexOf(getYearNumber(aDateString)) != -1)
	{	
		if(mnth > 2)
			leap = 1;
	};
	sumDays = dayCount + leap;
	for(i = 0; i< mnth-1; i++)
	{
		sumDays = sumDays + monthAmounts[i];
	};
	return sumDays;
	
};

function getDiffDates(systemDate,expireDate)
{

	reg systemYear = getYearNumber(systemDate);
	reg expireYear = getYearNumber(expireDate);
	reg cLeap = 0;
	reg diff = 0;
	if(systemYear < expireYear)
	{
		// how long to the end of the year
		if(leapYears.indexOf(systemYear) != -1)
		{
			cLeap = 1;
		}		
		diff = ((365+cLeap) - getDayOfDate(systemDate)) + getDayOfDate(expireDate);
	}
	if(expireYear < systemYear)
	{
		// how long to the end of last year
		reg allLastYear = getDayOfDate(expireDate.substring(0,4) +  "-12-31"); // days in the expire year
		diff = (alllastYear - getDayOfDate(expireDate)) + getDayOfDate(systemDate);
	}
	if (expireYear == systemYear)
	{
		diff = getDayOfDate(expireDate) - getDayOfDate(systemDate);
	}
	return diff;
};


reg mySDate = "2023-01-07T05:25:43.511Z";
reg myEDate = "2023-01-08T05:25:43.511Z";


Console.print(getDiffDates(mySDate,myEDate));
reg diffResult= getDiffDates(mySDate,myEDate);
if(diffResult >0 && diffResult < 30)
{
	Console.print("valid date");
}else{
	Console.print("******INVALID**** date");
}

[ustk]

@Lindon That seems convoluted because of the leap years of course. Now having a time in ms will allow you to do the same thing in two lines...

[Lindon]

@ustk said in Dates...:

@Lindon That seems convoluted because of the leap years of course. Now having a time in ms will allow you to do the same thing in two lines...

yeah - ish.... not really a problem - the diffDates was the worst offender - I dont think time in milliseconds is going to help with that - in fact I can see it being worse.. We really need a function that tells me how long to the end of the year for a given year...

as well as something sensible like

myDate = aGivenDate + 30

[ustk]

@Lindon Time in milliseconds take into account all leaps from 01-01-1970. So if you subtract two dates you'll get the exact number of milliseconds between the two, that you can convert up to the scale you want -> msDiff/1000/60/60/24 for days for instance.

[Lindon]

@ustk yeah I get that - and Im not obsessed about leap years - its not that hard to do...I'd just like a nice way to say

reg myDate = Time(Engine.getSystemTime);

and save all that text parsing...which would mean implementing Time::getCurrentTime()
or Time::currentTimeMillis()

..and whilst we are there:

Time::fromISO8601(StringRef iso8601) would be really helpful too...

So I guess I can already see a few more methods we could add right off the bat to make this waay more useful.

[ustk]

@Lindon Just adding a parameter to the actual function (or make a separate one...) and it's a one liner:

[Lindon]

@ustk good plan. I look forward to it. :-)

[ustk]

So I have finally created a separated class as Dave suggested that I weirdly called Timing...
Time couldn't be used as a class name because of a million conflicts, but other ideas are welcome

For now I have added 4 functions, let me know if you need more

Since it is just for a few conversion jobs, I don't think we actually need a Time object, but who knows... (well, except Christoph obviously :) )

[Christoph Hart]

Hmm, Timing is a pretty bad name for this as I would expect it to measure some benchmark stuff or handle MIDI delays etc.

What's the problem with Time? I'm not aware of any existing classes with this name and even if, I would prefer ´Date` as an API class (there's also a popular JS library with this name so it's a bit more close to our mother language.

[Christoph Hart]

reg leapYears = [1992,1996,2000,2004,2008,2012,2016,2020,2024,2028,2032]; //add more if you need em

Lol

inline function isLeapYear(year) 
{
    return year % 4 == 0;
}

[ustk]

@Christoph-Hart Simply because this was as far as my english brought me today

I tried Time but I encountered some conflicts with Juce Time, or I'm just idiot in the way I did it...

Date sounds good :thumbs_up:

[Christoph Hart]

@ustk ah your class doesn‘t need to be called Time in C++ the scripting name is determined by getObjectName().

[ustk]

@Christoph-Hart If you say so :man_shrugging: Could you say it again in french please?

EDIT: Oh ok I see :thumbs_up:

[d.healey]

Yeah I think date is a good choice since that's familiar to us Javascript people :)

[ustk]

@Christoph-Hart @d-healey @Lindon Pull request made (along with a few others)