Przemyslaw Czerpak wrote:
On Wed, 11 Feb 2009, Phil Barnett wrote:
Hi Phil,
I have no idea however, how to introduce offset in syntaxes in an elegant
way, especially in the fixed position format.
I believe that the last time this came up, I pointed out that I had
completed all the n
On Thu, 12 Feb 2009, Mindaugas Kavaliauskas wrote:
Hi Mindaugas,
> 3 Well a can not even understand the third choice. The truth is, that still
> do not understand string comparison in Clipper, but very well understand
> strcmp() behaviour.
So you can think about:
()
where is <, <=, >
>
> ,-
> | Of course it turned out that the period in which Daylight Saving Time
> | is in force cannot be given by a simple algorithm, one per country;
> | indeed, this period is determined by unpredictable political decisions
On Fri, 13 Feb 2009, Mindaugas Kavaliauskas wrote:
Hi Mindaugas,
>> Sorry but it's not enough.
>> But here we will have other problem
> I do not know, that will be the end decision of this discussion, but I do
> NOT see any good way to implement Time zones, or even Time offset in the
> cor
Sorry but it's not enough.
...
But here we will have other problem
Hi,
I do not know, that will be the end decision of this discussion, but I
do NOT see any good way to implement Time zones, or even Time offset in
the core of timestamp data typein some magic transparent way.
I think in
Hi Przemek,
> > To handle any more details than that it's a perfect job
> > for a 3rd party lib. Updating it here regularly is a nightmare.
> > > For such TZ updating we have to know the exact rules and any static
> > > _SET_UTC_OFFSET will not help because today in Poland we use CET
> > >
On Thu, 12 Feb 2009, Szak�ts Viktor wrote:
Hi Viktor,
> > 1. It will be necessary to hardcode TZ tables in Harbour source code
> > for each countries and years. It's not job for single developer because
> > it may not have enough knowledge about rules used for time conversions
> > and summe
Hi Viktor,
Il 12/02/2009 20.20, Viktor Szakáts ha scritto:
Hi Francesco,
Yes, interesting idea to remap a whole set of functions
to another namespace. This might help on the "sandboxing"
problem when running non-trusted scripts in an app
environment. If we define a namespace with all allowed
Hi Przemek,
> > No, I am not aware of a database that stores time zone with the date/time
> > value. I agree with Viktor - The date/time value stored in the database
> > must be timezone independent (ie. UTC 0). Then, the app can set some
> value
> > (eg. environment var) to align any date/time v
Hi Przemek,
Yes, I see your point - Make all date/time values (DB and in memory)
UTC 0 and only adjust what the user sees. This will have to happen at
the application level since there are many UI possibilities (eg. DOS,
Windows, Web). Perhaps add a special mask to be used with the
Transform(
Hi Francesco,
> Il 12/02/2009 19.17, Viktor Szakáts ha scritto:
>
>> We can even have these in parallel, and if we go this route, we should
>> gather all these _*() dialect prefixed functions in separate files
>> (for clarity and future development), and user can easily map the one they
>> need u
Hi Przemek,
> Not only DATEs but also TIMESTAMPs. Even if we'd fully honor TZ
> signature in our internal representation (this is quite easy)
Yes, I meant timestamp of course.
> then it does not resolve the problem how to restore it when TIMESTAMP
> value is exchange between Harbour and diffe
We also have to define relation operators behavior: ==, =, <, >, <=, >=
when DATE and TIMESTAMP are used.
We have the following choices:
1. compare only date part ignoring the time with the exception for ==
operator which will make exact comparison. For this exact comparision
we also have
On Thu, 12 Feb 2009, Randy Portnoff wrote:
Hi Randy,
> No, I am not aware of a database that stores time zone with the date/time
> value. I agree with Viktor - The date/time value stored in the database
> must be timezone independent (ie. UTC 0). Then, the app can set some value
> (eg. environ
Hi Viktor,
Il 12/02/2009 19.17, Viktor Szakáts ha scritto:
We can even have these in parallel, and if we go this route,
we should gather all these _*() dialect prefixed
functions in separate files (for clarity and future development),
and user can easily map the one they need using
"FUNC TTOS
On Thu, 12 Feb 2009, Szak�ts Viktor wrote:
Hi Viktor,
> > Which timezone we should set when DATETIME value is extracted from table,
> > f.e. ADT or DBF file or from some SQL RDBMS. Which database systems you
> > know that supports timezone or UTC offsets or at least binary UTC time
> > signature
Hi Przemek,
No, I am not aware of a database that stores time zone with the
date/time value. I agree with Viktor - The date/time value stored in
the database must be timezone independent (ie. UTC 0). Then, the app
can set some value (eg. environment var) to align any date/time
values read fro
>
> But can you say sth more.
> Which timezone we should set when DATETIME value is extracted from table,
> f.e. ADT or DBF file or from some SQL RDBMS. Which database systems you
> know that supports timezone or UTC offsets or at least binary UTC time
> signature in DATETIME values? Or maybe they
>
> We can but we used to not intorduce new public functions without HB_ prefix
> to not cause problems with 3-rd party or user code which may already use
> functions with the same names.
> Anyhow here we have yet another aspect. These functions are already
> implemented in some xbase compatible la
On Thu, 12 Feb 2009, toni...@fwi wrote:
Hi Toninho,
> +1, but IMO TIMESTAMP item not need be 0, in any case, only compare
> dates and ignore time.
So you vote for 1c where '==' operator works like '=' and only
Julian date is compared.
best regards,
Przemek
__
On Thu, 12 Feb 2009, Randy Portnoff wrote:
Hi Randy,
> Sorry if this was already covered, but the time zone should also be
> included in the datetime value and considered by the date-time
> functions/operators.
But can you say sth more.
Which timezone we should set when DATETIME value is extra
On Thu, 12 Feb 2009, Angel Pais wrote:
> Also:
> A date is represented in DBF as "MMDD"
No. It's only one of few representations in DBF format:
1. { "D", 8, 0 } // stirng as above
2. { "D", 4, 0 } // julian date as 32bit binary little endian integer number
3. { "D", 3, 0 } // julian date as
>We also have to define relation operators behavior: ==, =, <, >, <=, >=
>when DATE and TIMESTAMP are used.
>We have the following choices:
>1. compare only date part ignoring the time with the exception for ==
> operator which will make exact comparison. For this exact comparision
> we also ha
Sorry if this was already covered, but the time
zone should also be included in the datetime
value and considered by the date-time functions/operators.
At 11:20 AM 2/12/2009, you wrote:
Viktor Szakáts wrote:
>
> Hi Przemek,
>
> 3) by no means. 2) could be good, but not with this problemati
Viktor Szakáts wrote:
>
> Hi Przemek,
>
> 3) by no means. 2) could be good, but not with this problematic case,
> which is a very important and common expression.
>
> I vote for 1/b) as the most natural one.
>
+1
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.co
Also:
A date is represented in DBF as "MMDD"
Wil timestamp be represented in DBFS with 17 characters ?
eg: MMDDHHMMSSmmm bieng the last 3 millisecs.
Another one:
Why timestand has to have a literal representation since dates don't have it
?
In dates we use dtos(), stod(), dtoc() ctod()
Il 12/02/2009 15.57, Viktor Szakáts ha scritto:
Hi Przemek,
3) by no means. 2) could be good, but not with this problematic case,
which is a very important and common expression.
I vote for 1/b) as the most natural one.
+1
Best regards
Francesco
Hi Przemek,
3) by no means. 2) could be good, but not with this problematic case,
which is a very important and common expression.
I vote for 1/b) as the most natural one.
Brgds,
Viktor
On Thu, Feb 12, 2009 at 3:44 PM, Przemyslaw Czerpak wrote:
> Hi All,
>
> On Tue, 10 Feb 2009, Przemyslaw Cze
Hi All,
On Tue, 10 Feb 2009, Przemyslaw Czerpak wrote:
> We have to define also supported math operations and item type for results.
> I suggest to make it date compatible too and define that date + timestamp
> and timestamp + date gives timestamp as result. The list of legal operations
> will loo
> The main problem we have now is syntax which we should use for
> constant representation of timestamp (date + time) values in .prg code.
Just to add to the general mayhem, ODBC and MSSQL understand this FIXED
notation:
Date:
{d '-mm-dd'}
DateTime (timestamp):
{ts '-mm-dd hh:mm:ss'}
On Wed, 11 Feb 2009, Phil Barnett wrote:
Hi Phil,
>> I have no idea however, how to introduce offset in syntaxes in an elegant
>> way, especially in the fixed position format.
> I believe that the last time this came up, I pointed out that I had
> completed all the necessary julian functions in
Viktor Szakáts wrote:
Very ugly indeed. Well, I think offset is pretty much enough for most
practical business purposes, and it doesn't block the way for 3rd party
tools to implement "proper" (if we can use this word for the TZ system
of the world in practice ;) TZ support with all the gory det
>
> xbase++ go to be more visual fox pro compatible because a large user
> base will be given
> xbase++ have added new datatypes to the Xbase++ language such as
> datetime and interval. They are compatible with the VFP Timestamp typ
> xbase++ have added a /fox switch to the Xbase++ compiler to acce
xbase++ go to be more visual fox pro compatible because a large user
base will be given
xbase++ have added new datatypes to the Xbase++ language such as
datetime and interval. They are compatible with the VFP Timestamp typ
xbase++ have added a /fox switch to the Xbase++ compiler to accept the
"." i
BTW, I've just searched through the ACE 9.10 Client Engine (including the
local server), and I couldn't find any reference to
TTOS().
Where are the ADS supported index functions documented??
Brgds,
Viktor
On Wed, Feb 11, 2009 at 12:01 PM, Viktor Szakáts wrote:
> can do whatever you want, but if
>
> can do whatever you want, but if you want 100% support harbor index cdx,
> TTOS must exist to support them, not just visual fox pro, advantage also
> uses it for example.
>
> Why we need HB_TTOS() and TTOS() at the same time.
> I think TTOS is the best solution with HB_COMPAT_FOXPRO and without
Viktor Szakáts escribió:
Please function TTOS is necessary to fully support cdx indexes of
last version of dbf (implemented in vfp). Please don't add hb_ prefix
in this case, please don't add it.
You know we have a rule to add it for all Harbour extension
functions.
Depending on
? d + 0.5 + 0.5
> just compare Clipper and xHarbour results.
Just for fun... VO gives 'Conversion is not possible between Date and Float'
and 'Illegal Operation' and Vulcan.net sets it to 2/10/2009 (same as
Clipper)
Paul
___
Harbour mailing l
Hi Viktor,
Il 10/02/2009 19.02, Viktor Szakáts ha scritto:
Hi Przemek,
> I have no idea however, how to introduce offset in syntaxes in an
> elegant way, especially in the fixed position format.
t"-MM-DD hh:mm:ss.ccc"
can be extended by UTC+- sufix, f.e.:
>
> > Nice, but could we avoid this strange syntax t"" ?
> > I find it rather strange in Harbour.
>
> I find t"xyz" coherent with SQL where dates and times are simply literals.
Yes, but IMO it's not a very good idea to mix different language
concepts, Harbour is rooted in Clipper, not SQL.
> So
On Tue, Feb 10, 2009 at 7:02 PM, Viktor Szakáts wrote:
> Nice, but could we avoid this strange syntax t"" ?
> I find it rather strange in Harbour.
I find t"xyz" coherent with SQL where dates and times are simply literals.
Some examples are:
DATE'1999-12-25'
TIME'08:23:16'
TIME'14:23:16.5'
TIME
>
> hb_ctot( "2009-02-10 18:39:47 UTC+0100" ) => meaning 2009-02-10 18:39:47
>> UTC+0100
>> hb_ctot() could also accept all formats you wrote for t"":
>> hb_ctot( "01:00" )
>> hb_ctot( "01:58:27" )
>> hb_ctot( "2009-02-09" )
>>
>
> Only runtime function evaluation (without compilers pseudo-function
Miguel Angel Marchuet wrote:
Please function TTOS is necessary to fully support cdx indexes of
last version of dbf (implemented in vfp). Please don't add hb_ prefix
in this case, please don't add it.
Hi,
I'm not always a fan of HB_ prefix, but in final application it can be
solved, by:
FUNC
Hi,
hb_ctot( "2009-02-10 18:39:47 UTC+0100" ) => meaning 2009-02-10 18:39:47
UTC+0100
hb_ctot() could also accept all formats you wrote for t"":
hb_ctot( "01:00" )
hb_ctot( "01:58:27" )
hb_ctot( "2009-02-09" )
Only runtime function evaluation (without compilers pseudo-function
optimisation)
>
> Please function TTOS is necessary to fully support cdx indexes of
> last version of dbf (implemented in vfp). Please don't add hb_ prefix
> in this case, please don't add it.
You know we have a rule to add it for all Harbour extension
functions.
Depending on where TTOS() comes from, we may i
Hi Przemek,
> > I have no idea however, how to introduce offset in syntaxes in an
> > elegant way, especially in the fixed position format.
>
>
> t"-MM-DD hh:mm:ss.ccc"
> can be extended by UTC+- sufix, f.e.:
> t"2009-02-10 18:39:47 UTC+0100"
> It will be sth like output of:
> date
Instead, I'd suggest a set of function, just like Clipper
uses for dates:
- hb_time() ->
- hb_stot( "language independent string representation of date/time" )
->
- hb_ttos() -> language independent string repr of date/time,
easy to parse with fixed positions ("MMDDHHMMSSFF")
- hb_
On Tue, 10 Feb 2009, Szak�ts Viktor wrote:
Hi,
> We'd need some helpers though to free users from
> computing day fractions to/from normal everyday terms
> like hours, minutes and seconds. Those fractions are
> pretty cryptic in their raw form.
> One hour is 0.041667 day.
Here support for consta
Hi Przemek,
Thanks for the heads up. I'll start with what I can find, then if you have
other exmples, I'll be in touch.
btw, You're doing a great job - wish I had 10% of the energy you do :-)
Paul
On Tue, 10 Feb 2009, Paul Tucker wrote:
Hi Paul,
> pt> I also suggested if we don't know it
On Tue, 10 Feb 2009, Paul Tucker wrote:
Hi Paul,
> pt> I also suggested if we don't know it's broke, we can't fix it...
AFAIR only few examples of problems with xHarbour HVM I sent over
two year ago has been fixed and most of them still fails. Many of them
are even registered in xHarbour bug rep
Hi Przemek,
> The .prg level timestamp arithmetic for me should be as closed as possible
> to date one. I think that the best part of xHarbour datetime implementation
> is the possibilities to easy replace existing date fields with datetime
> ones
> and that the whole code works in the same way,
On Tue, 10 Feb 2009, Szak�ts Viktor wrote:
> > 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.
> My vote for the lat
My friends
All is well, Viktor and I cleared this up in email and he's ok with my
posting this:
===
Nope Paul, but I didn't even try very hard.
Building from source fails mainly because I no longer
maintain BISON/FLEX tools.
I've once tried some binaries, but failed for some reason I
cann
>
> 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.
My vote for the latter (millisecs).
> 2) does we need to include
Hi Paul,
Yes, I wrote it to the Harbour list.
What on earth? Pardon?
Brgds,
Viktor
On Tue, Feb 10, 2009 at 4:16 PM, Paul Tucker wrote:
>
>> xHarbour never built properly on my system, nor
>> could I use any binaries, so I'll skip that, but I believe you :)
>>
>>
> It looks like this quote came
On Tue, 10 Feb 2009 10:16:37 -0500
"Paul Tucker" wrote:
> >xHarbour never built properly on my system, nor
> >could I use any binaries, so I'll skip that, but I believe you :)
> >
>
> It looks like this quote came from you. What on earth are yoiu talking
> about?
Sh*t, for sure ;-)
--
Andi
__
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.
xHarbour never built properly on my system, nor
could I use any binaries, so I'll skip that, but I believe you :)
It looks like this quote came from you. What on earth are yoiu talking
about?
Paul
___
Harbour mailing list
Harbour@harbour-projec
Hi Przemek and all,
Okay, I understand the reasons and benefits, so it all
comes down how we implement it in Harbour.
I vote for adding a new type to have a clear case
rather than mixing this feature into current "D" type.
Besides creating backward compatibility problems
it would also make porting
Przemyslaw Czerpak wrote:
But I do not think that we can generalize it also for DATETIME type.
Just simply in current days in many database projects simple DATE fields
are replaced by DATETIME ones.
I currently have no use for them but when I have done some tests with
moving from dbfs to some
On Tue, 10 Feb 2009, Szak�ts Viktor wrote:
Hi Viktor,
> Sorry to jump it but I fail to see why should we rush a new proprietary type
> into the core, while it has a
> proper 3rd party solution.
> There could be lots of other types introduced into
> core by this reasoning.
In general I agree that
Hi Pritpal,
Sorry to jump it but I fail to see why should we rush a new proprietary type
into the core, while it has a
proper 3rd party solution.
There could be lots of other types introduced into
core by this reasoning.
Datetime's only "merit" seems that some proprietary
xbase dialects have alr
Hello Przemek
Can we have Date type as DateTimeStamp?
Francesco has sent me a solution to retrieve
datetime value from an com object but it returns it
as an object. This forces me to rewrite code
employing active-x controls.
This is the only feedback from my users
whenever they use my extende
63 matches
Mail list logo
