date comparison (or comparison between 2 numbers)

You can't compare those 2 date for 2 reasons.
1/ The number is a long, greater than 32 bits.
2/ Your future date is incorrect, with an extra 0 on the end.

The following will give you 2 numbers that are easy to work with
var future = Calendar.moment({
:year => 2015,
:month => 5,
:day => 22,
:hour => 17,
:minute => 0,
:second => 0}).value();

var now = Time.now().value() + System.getClockTime().timeZoneOffset;


You can't compare those 2 date for 2 reasons.
1/ The number is a long, greater than 32 bits.
2/ Your future date is incorrect, with an extra 0 on the end.

The following will give you 2 numbers that are easy to work with
var future = Calendar.moment({
:year => 2015,
:month => 5,
:day => 22,
:hour => 17,
:minute => 0,
:second => 0}).value();

var now = Time.now().value() + System.getClockTime().timeZoneOffset;


Thank you VERY much..

I've used it in the following manner tho
var FutureDate = Calendar.moment({:year => 2015,:month => 5,:day => 22,:hour => 17,:minute => 00,:second => 0});

function initialize() {
FutureDate = FutureDate.add(new Time.Duration(-Sys.getClockTime().timeZoneOffset));
}


and

if (futureDate.lessThan(now)) {
// Do Stuffs
}



TQ very much for the guidance.

I need some help debugging this code and why after the date comparison is done and the "greatherThan(now)" condition is met, it will still display the field. (my goal is to show the countdown and then remove the field once countdown finishes)

var eventName = [
"SAER",
"Klang",
"PD Dual",
"SCKLM"
];

var eventMoment = [
Calendar.moment({:year => 2015, :month => 4, :day => 5, :hour => 7, :minute => 30}),
Calendar.moment({:year => 2015, :month => 5, :day => 25, :hour => 9, :minute => 45}),
Calendar.moment({:year => 2015, :month => 8, :day => 2, :hour => 7, :minute => 00}),
Calendar.moment({:year => 2015, :month => 10, :day => 4, :hour => 4, :minute => 30})
];

....
....


for (var j = 0; j != eventMoment.size(); ++j) {
if (eventMoment[j].greaterThan(now) && i <= maxEvents ) { // I have space for 4 event lines only
Sys.println("111");
dc.drawText(25,y,Gfx.FONT_TINY,eventName[j],Gfx.TEXT_JUSTIFY_LEFT); // draw the event name
Sys.println("222");
dc.drawText(80,y,Gfx.FONT_TINY,updateCountDownTimer(j, eventMoment[j],now),Gfx.TEXT_JUSTIFY_LEFT); // draw and update the countdown timer.
y = y + 15;
i++;
Sys.println("333 \n");
}
}




the funny thing is - if I exit the watch (eg: select another CIQ Watchface, go out, then reselect the same watch face, the "finished" event will longer be there.

it seems like the code does not evaluate and update the watchface?

BTW - the date comparison code is all in onUpdate(dc) function. which by right - should be updated at every minute and I don't need to call ui.requestUpdate()

hope some one can help.

I believe that technically ++j should increment j before you use it?

In this case it doesn't matter. The return from ++j isn't being used in this context so from a correctness perspective, they are equal.

As you most likely know, but some of the new programmers out there might not know, there is a difference between ++j and j++. The former expression returns the value of j after the increment, and the latter returns value before the increment. In some languages, the difference can be significant (depending on the type of j) because it is necessary to make a copy of j before incrementing so that the previous value can be returned. In most languages I've dealt with, using prefix increment (++j) is preferred for this reason. Some consider it a premature optimization.

Personally, I prefer to use ++j unless I need the behavior of j++. The cost of pre-increment should never be greater than the cost of post-increment, and the amount of effort I put out for code that is potentially more efficient is zero.

++j and j++ (yea i understood it, but sometimes just chose to ignore it. LOL)

anyways - I did account for the TZO on the original code, but after fiddling with it for a while, I found that the LOCATION i placed the TZO offset was in error.
I placed it in the countdowntimer() function. This was AFTER the evaluation to determine if the time delta was > now.

That was the problem, it was AFTER and it have been accounted for BEFORE.

I've now placed the TZO offset at the initialise() function.

Thanks All!

....so from a correctness perspective, they are equal...

Well I maintain that ++j is misleading & not correct, because j is not actually incremented before being used.

Well I maintain that ++j is misleading & not correct, because j is not actually incremented before being used.

In this context, the fact that it is misleading does not matter. The result is not being used and the issue that arises from the misleading behavior does not occur.

This is essentially a religious war. I don't take issue with you having your own beliefs, but it seems inappropriate to try to just push them on others. That said, it is entirely reasonable to explain your belief, offer justification, and let people decide for themselves.

In this context, the fact that it is misleading does not matter.

I have to disagree, as it's far more than what works - it's how easy for a developer to understand years from now, be it you or someone else.

In this case, for a for loop like this, using x++ is the convention, and if you use ++x, it makes the reader of a code a bit confused as to why the non-conventional auto increment was used.

In coding, it's not always the "legitimacy" of the code, it's how well it can be understood by you or someone else. And there, conventions are important. If I saw code that didn't use "i++" but "i=i+1" instead, I'd think "someone just learning the language".

Trivia time! In the K+R days, the DEC CPUs (The PDP's were big back then!) had an increment and decrements machine instruction, so it was included in C! (and c++, etc, since) Doing "i=i+1" required multiple instructions, and those were the days where each byte counted!

.... the fact that it is misleading does not matter.

Isn't it inappropriate to try to just push your idea on others? ;) I'm pretty sure you have made comment simply because someone did not place their code in a code block when posting on the forum.