World: r3wp

I like that PICK is stopping point for none propagation. PICK data 
none should trigger an error, because otherwise you couldn't tell 
the difference between that and PICK [#[none]] 1.

is -> is a

We keep adding more points of none propagation, and every time we 
add one it makes more errors propagate further away from their point 
of origin. This makes it harder to figure out which code caused the 
error where none wasn't screened for or checked for, making it that 
much more difficult to debug.

We don't want REBOL code to be as difficult to debug as SQL.

Although PICK does propagate none indexes for datatypes where PICK 
acts the same as SELECT, such as map! or object!.

Tonight's Moment of REBOL Zen:

Literal and Get Arguments in R2

see: http://www.rebol.com/docs/core23/rebolcore-9.html#section-3.2

These functions use Literal Arguments:


 ++ -- ? ?? cd default deflag-face first+ flag-face flag-face? for 
 forall foreach forskip help l ls map-each remove-each repeat secure 
 set-font set-para source

This function uses Get Argument:

	quote

It could be questioned, why functions like

	get set unset in catch throw checksum


, which all have arguments named WORD, don't use Literal Arguments?

Lit-word arguments are for functions that treat words as keywords 
or part of the syntax, or for interactive command line functions 
that are supposed to act like shell funcs. If you use lit-word arguments, 
you can't easily generate the value passed using an expression, especially 
in R2 - in R3, those expressions can be put in parens, as is emulated 
in the R2 mezzanine backports of R3 functions that take lit-word 
arguments. For instance, if you made GET take a lit-word argument, 
GET IN wouldn't work.

The only exception to the above is ++ and --, which take lit-word 
arguments because their primary use is with a literal word value, 
so taking a lit-word argument gets rid of a ' in the most common 
case. And since ++ and -- started in R3 and has its behavior explicitly 
emulated in R2, you can put word-generating expressions in parens 
for the less common case.

FIRST+ is part of the same exception as ++ and --.

Does it make sense to have a timestamp datatype as distinct from 
a date type

Breakdown by reason:

- The word is pseudo-syntax for loop vars: FOR FORALL FOREACH FORSKIP 
MAP-EACH REMOVE-EACH REPEAT

- The function is pseudo-syntax for modifying operations on literal 
words as variables: ++ -- DEFAULT FIRST+

- Keyword arguments that aren't generally in expressions: DEFLAG-FACE 
FLAG-FACE FLAG-FACE? SECURE SET-FONT SET-PARA
- Interactive shell functions: CD LS ? ?? HELP SOURCE

>> to date! now
== 15-May-2011/10:41:51+12:00
>> to date! "15-May-2011"
== 15-May-2011

to date! creates two different types

A timestamp more precise than NOW/precise?

No, to date! creates either a date only , or a timestamp at present

it's inconsistent

it should create a date at 0:00 and GMT

if those are not provided

A source for errors ....

The date! type is a datetime type with an optional time portion. 
We can get rid of the time portion already. What do you want that 
we don't have already?

to date! should create a timezone and hour by default

But that doesn't work when you don't want a time and date.

>> d: now/date
== 14-May-2011
>> d: now d/time: none d
== 14-May-2011

When you requested a timestamp type, I thought you were requesting 
a timestamp type, not a datetime type.

in databases .. date and timestamp are different

In some SQL implementations, date, time and datetime are different. 
And then timestamp is different from all of those.

maybe just need an explicit to-datetime

A few SQL implementations call the datetime type "timestamp" for 
some cunfusing reason. It's best to keep the concepts distinct.

at present 'to-date gives you either a date, or a datetime depending 
on the input.  that is inconsistent

A TO-DATETIME function would be great. GMT by default, or local time 
like the rest of REBOL?

localtime would be consistent

In R3, GMT seems to be the default time zone. Interesting.

For many webservices I prefer to work with GMT

For me the issue is that when dealing with dates, I want to get only 
the date, but it it's a date with no time portion, then date/date 
gives you an error.

So, I have to check to see what it is first.

Or, maybe date/date should just not complain!

Better to have a to-datetime function though

to-datetime: func ["Converts to date! value." value][

    value: to date! :value unless value/time [value/time: 0:00 value/zone: 
    0:00] value
]

Should this be in /core ?

Don't see why not. It also is a simpler solution than splitting the 
date! type into date! and datetime!.

and just a refinement to default to local time

Given that R3 might get some restrictions, maybe having the /utc 
option like NOW would be better. Like this:

to-datetime: func ["Converts to date! value." value /utc "Universal 
time (no zone)"][

    value: to date! :value unless value/time [value/time: 0:00 value/zone: 
    either utc [0:00] [now/zone]] value
]

But that is starting to get more confusing, since /utc would only 
affect date values without times specified, not convert ones with 
times specified. It might be better to just say that it adds 0:00+0:00 
if not otherwise specified, since that is how dates are defined for 
date arithmetic compatibility between dates with times specified 
and those without.

Given that R3 might get some restrictions
 on the use of /local (there was a blog about it).

My other beef is how Rebol formats datetimes

look at this:

15-May-2011/11:15:59+12:00
15-May-2011/11:15:59+12:00
15-May-2011/11:16+12:00
15-May-2011/11:16+12:00

Why should the precision change ?

The precision didn't change. The date! type has fixed precision, 
not floating point. All missing parts are 0.

There are many competing and conflicting standards for how to format 
dates - REBOL just picked one of the international standards that 
looks more human-readable than most. You can get at the component 
parts if you want to format them differently.

Does 11:16:00 look less readable than 11:16 ?

Anyway, I raise this because most web services want times to a fixed 
degree of places.  Not varying by the second