Hi,
In general I agree that introducing many different types directly
to HVM is not good idea. Especially when they are strictly bound
with some allocated resources. For such types HB_IT_POINTER seems
to be the best choice.
But I do not think that we can generalize it also for DATETIME type.
I also think dattime (or Timestamp (it helps easier to find well-fit and
remember VALTYPE()=="T")) is necessary in Harbour.
We had a long discussion some time ago and could not agree on
implementations details. AFAIR, we main questions was:
1) internal implementation: float point number using fractional part for
time representation (drawback: float point side effects, ex.
today+8h+8h+8h != tomorrow, feature: easy calculation), or julian date
and milliseconds.
2) does we need to include timezone into timestamp;
3) timestamp representation in Harbour language.
I hoped that passing some time will make these things more clear to me,
but it had not.
condition between calling date() and seconds(). At midnight it may
give wrong results so it should be change to sth like:
func curdatetime()
local day, sec
while .t.
day := date()
sec := seconds()
if day == date()
exit
endif
enddo
return (day-ctod(""))+sec/86400
Yes. It really is a problem. I always feel doing a bad thing, then I
write: DTOC(DATE()) + " " + TIME().
In xHarbour simple DATE type is extended and can hold also time so it
does not use separate type for it. It's quite interesting solution but
it causes some small incompatibilities in DATE type arithmetic which can
be illustrated by this example:
d := date()
? d
? d + 1
? d + 0.5
? d + 0.5 + 0.5
just compare Clipper and xHarbour results.
I do not have xHarbour on my computer any more, but I think we will be
unable to change Date time to work like Datetime type and to be
compatible with Clipper. Since compatibility is important, we must
implement new type.
The second part is declaring DATETIME constants in source code.
It's not strictly necessary (f.e. Clipper does not support DATE constants
at all) but it's usable. xHarbour uses VFP syntax here:
VFP strict datetime format looks like:
{^YYYY/MM/DD[,][HH[:MM[:SS][.CCC]][A|P]]}
VFP accepts slash, dot or hyphen as date delimiter and 12 or 24-hour
formatted time.
If only hours are included in time part then comma have to be used to
separate date and time parts or it's necessary to follow the hours with
a colon.
This VFP syntax looks very ugly to me. It makes me feel, that date is a
kind of array (because of starting "{"). I would prefer "0t" prefixed
numbers 0t20080209235959. If this becomes cryptic and difficult to
separate date, time, milliseconds part, and we want to have string style
(containing ":" separator between hours, minutes, seconds, etc.) time
syntax, I'd rather suggest to use the existing quoted string prefixing:
tTimeStamp := t"2009-02-09 23:59:59".
The similar way timestamps are represented in SQL databases. My SQL uses
'2009-02-09 23:59:59' or 20080209235959 notation for TIMESTAMP type.
We can also look for timestamp representation in other languages.
In the semi PP notation this format can be defined as:
{ ^ <YEAR> <sep:/.-> <MONTH> <sep:/.-> <DAY> [[<sep2:,>]
[ <HOUR> [ : <MIN> [ : <SEC> [ . <FRAQ> ] ] ] [A[M]|P[M]] ] }
One minor note on date separator. Using "/" always makes confusion,
because you never now if it is MM/DD/YY or DD/MM/YY. Adding YY/MM/DD is
making problem even worse. I prefer to use "-" as date separator (BWT,
AFAIK its ANSI standard). We can use "/" also, but compiler should be
date format independent, so, people using "/" should expect result like:
SET(4, "MM/DD/YY")
tTimeStamp := t"08/02/09 23:59:59"
? tTimeStamp // prints: 02/09/08 23:59:59
In xHarbour it's also possible to use only time part, f.e.:
? { ^ 17:55:20 }
but here xHarbour sets in hidden way the day to 1899/12/30 so the
above code shows:
1899/12/30 17:55:20.00
I guess it's for some strict VFP and/or MS products compatibility.
I do not like it. It introduce sth what breaks DATETIME arithmetic.
I think we should not follow VFP in multiplatform project. For me it is
natural, that time only value has a zero julian date part.
Regards,
Mindaugas
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
