Should be changed from

(days since 2000)

to

(days since ():: sensing)

Dy155 wrote:

Should be changed from

(days since 2000)

to

(days since ():: sensing)

? Why should it be change?

Scratcher1002 wrote:

Dy155 wrote:

Should be changed from

(days since 2000)

to

(days since ():: sensing)

? Why should it be change?

Because what if a scratcher wants to know the exact number of days since not 2000?
Even though its workaroundable:

((days since 2000) - ((...) * (pick random (365) to (366))))

or

((days since 2000) + ((...) * (pick random (365) to (366))))

Dy155 wrote:

Scratcher1002 wrote:

Dy155 wrote:

Should be changed from

(days since 2000)

to

(days since ():: sensing)

? Why should it be change?

Because what if a scratcher wants to know the exact number of days since not 2000?

Then use your workaround. No support.

DaSpudLord wrote:

Dy155 wrote:

Scratcher1002 wrote:

Dy155 wrote:

Should be changed from

(days since 2000)

to

(days since ():: sensing)

? Why should it be change?

Because what if a scratcher wants to know the exact number of days since not 2000?

Then use your workaround. No support.

the workaround is clunky, support!

chuckdaboss wrote:

DaSpudLord wrote:

Dy155 wrote:

Scratcher1002 wrote:

Dy155 wrote:

Should be changed from

(days since 2000)

to

(days since ():: sensing)

? Why should it be change?

Because what if a scratcher wants to know the exact number of days since not 2000?

Then use your workaround. No support.

the workaround is clunky, support!

thanks!

You ought to be able to use some combination of

(current [day v])
(current [month v])
(current [year v])
(current [date v])

and a forumula that includes

 <<<((year) mod (4)) = [0]> and <not <((year) mod (100)) = [0]>>> and <(month) > [2]>>

plus an array of days in a month to write your own ‘days since’ function (which you can check using 1/1/2000 as a baseline)

No thank you.
1. We can only report number of days since 2000.

cs293450 wrote:

No thank you.
1. We can only report number of days since 2000.

If you don't support, don't necro.

2. This block is required.

(days since 2000)

Semi-support, because there's leap years and all that. I don't think the days since 2000 block should be removed, though.

How would a date be entered into the number input? Also I don't think we should get rid of the Days since 2000 block since I use it more than I use the timer block for the same purpose. It's also useful for making the seconds hand go smoothly on analog clocks, determining time zones, and finding the current millisecond.

I'd really like a milliseconds since 2000 and a “turn date into timestamp (time)”, days with (name) seems a little strange compared to (milli)seconds

gtoal wrote:

You ought to be able to use some combination of

(current [day v])
(current [month v])
(current [year v])
(current [date v])

and a forumula that includes

 <<<((year) mod (4)) = [0]> and <not <((year) mod (100)) = [0]>>> and <(month) > [2]>>

plus an array of days in a month to write your own ‘days since’ function (which you can check using 1/1/2000 as a baseline)

no all the people knows to do that hards workarounds, support for the post

cs293450 wrote:

2. This block is required.

(days since 2000)

he is not suggesting to remove the block

I'm trying to think of how changing this block is useful.

Nope, can't see how.
1) it's actually very useful for clocks etc.
2) there's a simple workaround you yourself stated.
3) don't fix something that ain't broke.

Sigton

No support, considering you provided two easy workarounds

support

Support! Make a

Days till ( )::sensing

block.
The number input is a year. If it is something like 2015 it would be a negative number. If it is 2017 it would be positive.

I don't really see any usefulness in the days since 2000 block, there's nothing that can go against its removal, however I do not see a practical use in a

(days since () )

block. And because of that, despite the cumbersome workaround, I do not support.