World: r3wp

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

So, my sugggestion is that the number of displayed places should 
always be consistent

Does 11:16:00 look less readable than 11:16 ?
 - Yes.

not less readable to a web service though

The default formatter is pretty much for situations where you don't 
need that kind of inflexibility. Most people don't need the whole 
gamut of different formatting options, since only a small percentage 
of them are used in any given situation. It would be useful to have 
a library of date formatting routines that could support all of the 
many standards. If you need to talk to a service that requires a 
particular format, use a particular formatter.

MOLD only has to be compatible with REBOL syntax, and the more human-readable 
subset at that. To be compatible with less flexible data formats, 
use formatting functions that are specific to those formats.