r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

GrahamC
14-May-2011
[1442x4]
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
BrianH
14-May-2011
[1446]
to-datetime: func ["Converts to date! value." value][

    value: to date! :value unless value/time [value/time: 0:00 value/zone: 
    0:00] value
]
GrahamC
14-May-2011
[1447]
Should this be in /core ?
BrianH
14-May-2011
[1448]
Don't see why not. It also is a simpler solution than splitting the 
date! type into date! and datetime!.
GrahamC
14-May-2011
[1449]
and just a refinement to default to local time
BrianH
14-May-2011
[1450x2]
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).
GrahamC
14-May-2011
[1452x3]
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 ?
BrianH
14-May-2011
[1455x2]
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.
GrahamC
14-May-2011
[1457x3]
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
BrianH
14-May-2011
[1460]
Does 11:16:00 look less readable than 11:16 ?
 - Yes.
GrahamC
14-May-2011
[1461]
not less readable to a web service though
BrianH
14-May-2011
[1462x2]
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.
GrahamC
14-May-2011
[1464x2]
My point is that I think it's an optimization that has bitten more 
than a few people
Maarten's S3 lib has a bug on this account.
BrianH
14-May-2011
[1466]
Date formats have that effect throughout the industry, mostly due 
to the vast number of incompatible formats to choose between. Whatever 
format you choose will be bad for most of the rest of the world.
GrahamC
14-May-2011
[1467]
As long as it works for my world and web services
BrianH
14-May-2011
[1468]
That is not what MOLD is for, that is a job for custom formatting 
functions.
GrahamC
14-May-2011
[1469x2]
So, what do you suggest?

>> d: 15-may-2011/12:00:00.00
== 15-May-2011/12:00
>> d/time
== 12:00
I think I'd like to see a flag or something that sets the number 
of decimal places for decimals, and number of places for time.
BrianH
14-May-2011
[1471]
Given that the "missing" parts of the precision aren't actually missing, 
sure, that works. And the standard allows those portions to be not 
depicted, just assumed. If you have to generate something less flexible, 
that is a *different* standard, so a different formatting function 
is appropriate.
GrahamC
14-May-2011
[1472]
Maybe that different formatting should be standard
BrianH
14-May-2011
[1473]
Keep in mind that times in REBOL and most other systems are fixed-point, 
not floating point. There is no loss of precision.
GrahamC
14-May-2011
[1474]
Having something that changes the display depending on what time 
it is ... is ... annoying
BrianH
14-May-2011
[1475x2]
That diferent formatting should not be standard. Generating code 
that is more complex than it needs to be is just a waste of space. 
Remember that MOLD output need only be compatible with REBOL code, 
not with any other syntax processor, and you see that it isn't a 
problem.
Decimals aren't output with 17 zeroes either, because that would 
be a waste of space.
GrahamC
14-May-2011
[1477]
True, we just get unintelligble scientific notation
BrianH
14-May-2011
[1478]
>> 1.00000000000000000
== 1.0
What you are suggesting is this, but for dates:
>> 1.0
== 1.00000000000000000
GrahamC
14-May-2011
[1479]
>> d: .01
== 1E-2
BrianH
14-May-2011
[1480]
Keep in mind that the main intended purpose of MOLD is to generate 
REBOL source code. You are suggesting that it generate more complex, 
larger source code.
GrahamC
14-May-2011
[1481x3]
Yes, I'm suggesting that a system wide flag should control the display
I just can't imagine any scenario when the above example is useful
ie. 1E-2
BrianH
14-May-2011
[1484]
Settable system-wide flags that affect MOLD are a bad idea, since 
they mean that you have to put wrapper code around every call to 
MOLD to make sure that it matches what your code expects. This makes 
very call to MOLD more complex and less task-safe.
GrahamC
14-May-2011
[1485]
R2 has no tasks
BrianH
14-May-2011
[1486x5]
Recursion-safe then, or async-safe, whatever. Yes, this includes 
system/options/decimal-digits.
That is why there is a proposal for R3 to make all such options be 
specified at the point of call, not globally. Any global option like 
that would be protected from modification, or else it wouldn't be 
allowed.
This would mean that you would replace this code:
    saved: system/options/binary-base
    system/options/binary-base: 64  ; or 16, whatever
    output: mold data
    system/options/binary-base: saved
with this:
    output: mold/with data [binary-base: 64]


This saves code since you can't trust that any global option will 
remain even its default value without data flow analysis unless it's 
protected.
In any case, you were still leaving parts out of your date formatting. 
If you left it all in it would look like this:
>> 15-may-2011/12:00:00.00
>> 15-May-2011/12:00:00.000000+00:00
Sorry, I forgot 3 zeroes: 15-May-2011/12:00:00.000000000+00:00
GrahamC
14-May-2011
[1491]
I'd prefer that