Hi ,

I have problem with comparing negative datetime values in fcl-db test suite (accessed as variants).
It is related to VariantToDate function (in cvarutil.inc), where result is tested against MinDateTime.

For example:
  v1 :=strtodatetime('01.01.0001 12:00:00');
  v2 :=strtodatetime('01.01.0001 13:00:00');
  if v2>v1 then ... //<--exception here

Exception is raised because v2<MinDateTime { 01/01/0001 12:00:00.000 AM }. But logicaly on timeline is "v2" after "v1".

What do you think, can we change MinDateTime from -693593.0 to -693594.0; (to accept 01/01/0001 23:59:59.999)
...

-Laco.

What's the rationale for a restriction at all?

DoDi

LacaK wrote

What do you think, can we change MinDateTime from -693593.0 to -693594.0; (to accept 01/01/0001 23:59:59.999)

Jonas

Jonas Maebe wrote / napísal(a):

Thanks, it seems, that Joost in 2007 has falling in same problem as I now, when working on fcl-db test suite.
(now I catch this also when working on fcl-db test suite) I guess, that he has wrote tests for dates '01/01/0001' and now I am writting test for datetimes '01/01/0001 00:00:01' to '01/01/0001 23:59:59'. So if this constant can not be changed, then I must write workaround for date '01/01/0001' and do not add time part to this date.

L.

Negative dates are problematic as Year 0 officially does not exist. the first day of Year 1 is directly preceded by the last day of year 1 BC.

Many years ago I wrote a set of date handling functions for Jedi. Those became obsolete when a newer Delphi VCL version included a much improved set of date function. Maybe some of my old stuff (e.g. handling of negative dates) might still be of some interest.

-Michael

There exist other calendars than only the Gregorian one, with their own oddities (Maya!), and all of them should be based on an common internal date/time type.

IMO a MinDateTime value should be private to every calendar, if ever needed, and the global constant should be removed.

DoDi

Hans-Peter Diettrich wrote

There exist other calendars than only the Gregorian one, with their own oddities (Maya!), and all of them should be based on an common internal date/time type.

I've never heard that our DateTime routines support other calendars. My guess is that they simply don't.

Felipe Monteiro de Carvalho wrote

I've never heard that our DateTime routines support other calendars. My guess is that they simply don't.

Even so, does that mean we can't write software with FPC for use by Historian's where they might catalog artifacts with a date less that Year 100? I haven't tested, but if so, that's terrible.

Felipe Monteiro de Carvalho wrote

I've never heard that our DateTime routines support other calendars. My guess is that they simply don't.

Perhaps they should !

My favorite is the really natural one: Plank-time count since the Big Bang. Here supposedly we don't need negative values.,

-Michael

My favorite is the really natural one: Plank-time count since the Big Bang. Here supposedly we don't need negative values.,

Good joke! ;-)))
(but nobody knows, when it was (how many mld. years ago) and many doubts, that it is real fact)
-Laco.

LacaK wrote

So if this constant can not be changed, then I must write workaround for date '01/01/0001' and do not add time part to this date.

The constant was already changed once, and no-one complained in the following years, so my guess is that it could be changed again or even eliminated.

See:

Graeme Geldenhuys wrote

Even so, does that mean we can't write software with FPC for use by Historian's where they might catalog artifacts with a date less that Year 100?  I haven't tested, but if so, that's terrible.

You quoted my text in which I said that DateTime does not support other calendars, for example Maja. The limit of dates is not related to that.

In our previous episode, Felipe Monteiro de Carvalho said: [ Charset ISO-8859-1 unsupported, converting... ]

I think sacrificing dates from the year 1 to 100 AD to keep old two digit databases working is a small price to pay.

If the test doesn't take this into account, the test is simply wrong.

Maybe the difference between "datetime" and "time" or "datetime-difference" must be strengthened.

Felipe Monteiro de Carvalho wrote / napísal(a):

I think so also.

But my hotfix for this moment is skip testing datetimes '0001-01-01' with time portion.
As you can view here http://bugs.freepascal.org/view.php?id=19878 in toolsunit.diff

SQL standard ofcourse allows datetimes from '0001-01-01 00:00:00' to '0001-01-01 23:59:59'

-Laco.

Marco van de Voort wrote

I think sacrificing dates from the year 1 to 100 AD to keep old two digit databases working is a small price to pay.

But if I understand the situation correctly, dates 1 to 100AD are already supported in FPC and no-one complayned about old databases in the last years since the change made by Joost.

Lacak only asked to add 1 more day to our date limit.

Hello FPC,

Thursday, August 4, 2011, 10:11:16 AM, you wrote:

Felipe Monteiro de Carvalho wrote

> > I've never heard that our DateTime routines support other calendars. > My guess is that they simply don't.

GG> Even so, does that mean we can't write software with FPC for use by GG> Historian's where they might catalog artifacts with a date less that GG> Year 100? I haven't tested, but if so, that's terrible.

You need to use a dates library, usual simple date libraries like the fpc/delphi rtl are plain wrong for gregorian calendar prior 1582, so dates before (like the 100) mindate limit is meaningless. Just the october 5 1582 does not exists. Even in gregorian calendar if you live in Turkey the mindate value should be 1/1/1926. Dates and unicode suffers the same localization problems.

Felipe Monteiro de Carvalho wrote / napísal(a):

Exactly so!

And MinDateTime is used only in these two conversions functions (to test if result value is < MinDateTime):
FloatToDateTime and VariantToDate

-Laco.

Graeme Geldenhuys wrote

Even so, does that mean we can't write software with FPC for use by Historian's where they might catalog artifacts with a date less that Year 100? I haven't tested, but if so, that's terrible.

Hmm . What week-day and what month was day 1.000.000 BC ?

Did the Dinosaurs work that day even if it was a Sunday ?

If it was January, was this in Winter on the northern Hemisphere ? (Where was North, anyway...)

-Michael (having his funny day today)

+1

DoDi

The date representation by floating point numbers has a big advantage here: far away dates loose accuracy, so that it will be impossible to specify a time, or even specific days in such a date :-)

Did the Dinosaurs work that day even if it was a Sunday ?

We may end up with an answer like "42" (+- some billion years) for the date of the big bang, due to that inaccuracy. Isn't it nice how IT denies more concrete calculations, and consequently is neutral in disputes about the origin of the universe? ;-)

DoDi

People needing this should use specialized libraries which support this.