Is there a bug with setDate() ?

I'm having a problem using setDate() and there appears to be a bug. Here's some simplified code to try:

var x=0;
setInterval(function(){digitalWrite(LED1,x); x=!x;}, 500);

console.log(getTime());

//setTime(1000); 

console.log(getTime());

This works as expected - the red LED flashed every 500ms.

Now uncomment the setTime(1000) and try again - the Time is not set and the interval stops working!

I need to power Espruino off/on to get timer functions working again - not even a reset() helps.

Thanks - I'll look into this... setTime was added more for the F4 devices where there's a full calendar internally though.

On the F103 the suggested way of keeping time is this: http://www.espruino.com/clock

  var Clock = require("clock").Clock;
  var clk=new Clock("Jun 23, 2014 12:18:02");

  // every time the button is pressed, print the current time..
  function doStuff() {
    var d=clk.getDate(); 
    print(d.toString()); 
  }

That doesn't involve using setTime, so should still work fine.

I am currently using the Clock module so no real inconvenience if setTime() is F4 specific.

I just tried it because in your response to an earlier message stated that

1v71 will have some changes so that it remembers the current time after a hard reset ".

I was wondering how this would work (since the current time is held within a Clock object) - I then noticed setTime() and thought I would try it.

Thanks.

Ahh - well, when you create a Clock object, it remembers the time you supplied and the value of getTime() at the time you created it. Then, when you ask for the current time, it does:

theDateYouGave + getTime() - getTimeWhenDateSupplied

So in 1v71, even if you reset the board the Clock should still supply the right time.

The board has an internal real-time clock that will always store the correct time, and in pre-1v71 releases it was always reset on startup. In 1v71 I'm just detecting if the clock is already running, and if it is I leave it alone :)

But surely the Clock Object (which holds "theDateYouGave" and "getTimeWhenDateSupplied") will be lost by a reset (hard or soft) so getTime() will have no meaning after a reset?

@Gordon, is it possible write to the getTime() value holder? If so, the Clock object could get a method - say: push() - that would write the 'absolute' - actually any - time back to that holder and the holder now holds the 'unix birth date' or any offset date, for example AD. On a reset it is easy to detect - by the app code - if the time has been set or not - and then create a clock object with a pop()... or a-like. If the getTime() value cannot be written back, storing a 'difference' of value 'somewhere' where it survives a reset can be used to restore the 'absolute' time again. And again, it is easy to the app to detect whether the 'difference' has been set or not. Later solution would be: create a meaningful value with two meaningless values (offset of offset).

Well, the idea is that you use save() to save everything (including those two values) into flash... You can always call save() from your own code as well, if you want to allow the user to set the time in a way that'll survive resets.

setTime() would be better for allowing the user to change the time - however I wonder how many cases there are where the board would end up being hard reset by the user... Usually you'd just set it up and have it stay working until the battery ran down.

Ic, absolutely.

Since though no software is bug free - virtually never - things may ultimately freeze up. It happens still on a regular basis with stuff I ran, and it is so bad that the board is not even accepting commands from the console nor new code anymore. I did not have the time yet for a deeper analysis why it got there. For now I just observe to collect hints. With the setBusyIndicator() set to LED#, I hope to have some additional tool to see whether it is frozen all the way through - which I cannot believe - or if it is just way too busy - with some stupid short infinite loop - to receive commands from the console or new code and start over with. To get out of the misery, I just disconnect (w/ Chrome < 38.####) unplug the usb to the board, wait a few seconds, and plug it back in.

A hard reset should always be provided (...like a 'factory reset'). It should not be the biggest and most convenient function to be reached... but a little hole through which with a pin / paperclip the reset can be reached... (CD drives have it to physically retrieve (rescue) a CD (a real hard-hard-reset), the Palm devices had it... and many other device give the option in one way or another to have a factory reset.