headers
Graeme Geldenhuys | 1 Mar 08:48
Picon
Gravatar

Re: StrToDate error

Hi,

On 2/28/07, Michael Van Canneyt <michael <at> freepascal.org> wrote:

> You should not have to worry about it. You use TDateTime, and convert to
> string as needed as the user sees fit.
>
> I don't agree with Graeme's solution: it's not up to the programmer
> to decide how the date/time is shown to the user. The user has decided
> that for us when he configured his regional/localization settings.

Both you and Peter V. misunderstood my post slightly. You don't have
to force the user to see the date/time in a certain format.  Though we
opted for it after a length discussion.   Storing the date/time as a
string in the ISO 8601 format is forced and allows you to export data
to another application without having to try and guess the date format
 in the new application (yyyymmdd, ddmmyyyy, mmddyyyy, etc).

Once the string date/time  is read and converted it to a TDateTime,
the GUI can displays it in the way the user specified in their
regional settings, but as soon as it goes back to the database or some
file, it gets converted back to the ISO string format.

So bottom line, the user sees the date/time it the format they prefer.
This is the first choice. We opted to follow the ISO
8601recommendation for display as well, to help remove confusion
between various date formats in digital or hardcopy form.

Imagine the following case:
The user in USA generates a report with date/time columns as a PDF
(Continue reading)

Permalink | Reply | 11 comments |
headers
tanila | 1 Mar 08:50
Picon

Can´t find unit Interfaces...

Hello,

I use Lazarus SVN Rev. 10700
If I compile any projekt I got following compiler message:

project1.lpr(1,1) Fatal: Can't find unit Graphics

I am shure that this unit exists and is in the Searchpaths (-Fu).
I tried it with an emty LCL Application, too.

Has anybody the same problem and maybe fixed it somehow ?

greetings
tanila
Permalink | Reply | 3 comments |
headers
Michael Van Canneyt | 1 Mar 08:59
Picon
Favicon

Re: StrToDate error


On Thu, 1 Mar 2007, Graeme Geldenhuys wrote:

> Hi,
> 
> On 2/28/07, Michael Van Canneyt <michael <at> freepascal.org> wrote:
> 
> > You should not have to worry about it. You use TDateTime, and convert to
> > string as needed as the user sees fit.
> >
> > I don't agree with Graeme's solution: it's not up to the programmer
> > to decide how the date/time is shown to the user. The user has decided
> > that for us when he configured his regional/localization settings.
> 
> Both you and Peter V. misunderstood my post slightly. You don't have
> to force the user to see the date/time in a certain format.  Though we
> opted for it after a length discussion.   Storing the date/time as a
> string in the ISO 8601 format is forced and allows you to export data
> to another application without having to try and guess the date format
> in the new application (yyyymmdd, ddmmyyyy, mmddyyyy, etc).

You don't need to guess if it's in the database native format ?

> 
> Once the string date/time  is read and converted it to a TDateTime,
> the GUI can displays it in the way the user specified in their
> regional settings, but as soon as it goes back to the database or some
> file, it gets converted back to the ISO string format.
> 
> So bottom line, the user sees the date/time it the format they prefer.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Graeme Geldenhuys | 1 Mar 09:38
Picon
Gravatar

Re: StrToDate error

On 3/1/07, Michael Van Canneyt <michael.vancanneyt <at> wisa.be> wrote:
> > opted for it after a length discussion.   Storing the date/time as a
> > string in the ISO 8601 format is forced and allows you to export data
> > to another application without having to try and guess the date format
> > in the new application (yyyymmdd, ddmmyyyy, mmddyyyy, etc).
>
> You don't need to guess if it's in the database native format ?

That wasn't our experience with MS SQL Server 2000 which uses the US
date/time format even though the server was installed in the UK with
UK regional settings. We had similar issues (can't remember exactly
what) with Firebird.  Hence the reason we now store it as strings.

> "the user sees the date/time it the format they prefer."
>
> "We opted to follow the ISO 8601recommendation for display as well"
>
> Which one is it ? You can't have both :-)

hehe... ok reading my post again I can see it wasn't very clear.  ISO
8601 is a recommendation, it doesn't force anything.  The same goes
for the helper functions I wrote.

 function tiDateTimeAsIntlDateStor(const ADateTime: TDateTime): string;
 function tiDateTimeAsIntlDateDisp(const ADateTime: TDateTime): string;
 function tiIntlDateStorAsDateTime(const AValue: string): TDateTime;
 function tiIntlDateDispAsDateTime(const AValue: string): TDateTime;

After a length discussion in our company regarding previous versions
of our application, we had experienced a lot of confusion with date
(Continue reading)

Permalink | Reply | 7 comments |
headers
Michael Van Canneyt | 1 Mar 09:53
Picon
Favicon

Re: StrToDate error


On Thu, 1 Mar 2007, Graeme Geldenhuys wrote:

> On 3/1/07, Michael Van Canneyt <michael.vancanneyt <at> wisa.be> wrote:
> > > opted for it after a length discussion.   Storing the date/time as a
> > > string in the ISO 8601 format is forced and allows you to export data
> > > to another application without having to try and guess the date format
> > > in the new application (yyyymmdd, ddmmyyyy, mmddyyyy, etc).
> >
> > You don't need to guess if it's in the database native format ?
> 
> That wasn't our experience with MS SQL Server 2000 which uses the US
> date/time format even though the server was installed in the UK with
> UK regional settings. We had similar issues (can't remember exactly
> what) with Firebird.  Hence the reason we now store it as strings.

I use Firebird. 

Firebird stores date/time stamps as a 8-byte internal format.
The database engine returns you the value in this internal format,
so it's up to the database API to convert this to TDateTime.

When doing a query, i.e. in a SQL statement, you must indeed use 
MM/DD/YYYY. If you use parametrized queries, you must use the
internal representation. 

So there is no problem. You need exactly 2 routines:
TDateTime -> Firebird internal format.
Firebird internal format -> TDateTime.
These should normally be in your data access layer (FBLib, IBX, UIB, SQLDB)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Graeme Geldenhuys | 1 Mar 10:07
Picon
Gravatar

Re: StrToDate error

On 3/1/07, Michael Van Canneyt <michael.vancanneyt <at> wisa.be> wrote:

> When doing a query, i.e. in a SQL statement, you must indeed use
> MM/DD/YYYY. If you use parametrized queries, you must use the
> internal representation.

That's the one! We had some very huge and complex stored procedures
(couple hundred lines or sql) that used or generated dates on the fly
and was always an issue. And no, I didn't write those stored
procedure, but had to maintain them - a nightmare.  I still think it
is weird though. Installing a server in a location other that the US
and other than US regional settings, yet you have to convert to US
format dates.

Don't you just love software developers and the power that goes with it. :-)

--

-- 
Graeme Geldenhuys

There's no place like S34° 03.168'  E018° 49.342'
Permalink | Reply | 0 comments |
headers
Joost van der Sluis | 1 Mar 10:41
Picon
Gravatar

Re: StrToDate error

> That wasn't our experience with MS SQL Server 2000 which uses the US
> date/time format even though the server was installed in the UK with
> UK regional settings. We had similar issues (can't remember exactly
> what) with Firebird.  Hence the reason we now store it as strings.

Ok, so there's a bug in the data-layer, db-component or database-server
regarding TDateTime fields, so you decided to store it as a string?

If there's a bug regarding numerical fields, do you also store them as
strings? Or do you fix the bug? (Use another database-server?)

MS SQL stores date/time fields in a TDateTime format. (That's why it's
such a strange format.) Firebird uses something similar. The client-
library has to convert that. If that conversion goes wrong, that's
simply a a bug. But understandable, since if you use a simple 'select
datefield from table', without using parameters, it'll return the field
in a string-format, depending on the database-server settings, the
client settings and the connection/transaction settings. The program
which retrieves the field, should be aware of that. If it doesn't that's
just a bug.

It's exactly the same as with your solution: the application has to know
in which format the string comes. (in your case some iso-standard)
Only the 'build-in'-system is more flexible. You can set the format you
want yourself. (including your ISO-standard.) So instead of rewriting
everything in string-based fields, you could do a 'set
dateformat=isoXXXX' or something similar when you open a connection...

And third-party software can set it to their own needs...
(Continue reading)

Permalink | Reply | 4 comments |
headers
Graeme Geldenhuys | 1 Mar 11:04
Picon
Gravatar

Re: StrToDate error

On 3/1/07, Joost van der Sluis <joost <at> cnoc.nl> wrote:

> MS SQL stores date/time fields in a TDateTime format. (That's why it's
> such a strange format.) Firebird uses something similar. The client-
> library has to convert that. If that conversion goes wrong, that's
> simply a a bug. But understandable, since if you use a simple 'select
> datefield from table', without using parameters, it'll return the field
> in a string-format, depending on the database-server settings, the
> client settings and the connection/transaction settings. The program
> which retrieves the field, should be aware of that. If it doesn't that's
> just a bug.

I clearly can't get my point across today.  :-)

It was not a issue with the DB components we used at the time, but
rather with our complex stored procedures and the amount of people
that worked on the code.  Doing a normal select statement and
displaying that date worked fine.  It was when we had to write stored
procedures that generates dates based on special criteria and then use
those dates to query data.  This happened often and trying to remember
that the date format must be in a format you normally don't use
obviously was a issue. ;-)

> Only the 'build-in'-system is more flexible. You can set the format you
> want yourself. (including your ISO-standard.) So instead of rewriting
> everything in string-based fields, you could do a 'set
> dateformat=isoXXXX' or something similar when you open a connection...

Does this apply to code in stored procedures as well?  I would think
it only works with whatever DB component you use.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pieter Valentijn | 1 Mar 11:29
Picon

RE: StrToDate error

I agree that when you can you should use TDateTime but there are cases
where string presentation for storage is needed. Lets say we make a
export / import function in a CSV file.

There needs to be a contract on how to store dates (and numbers for that
sake) that is the same.

Displaying to me is best left to the operating system. Now with that
date as a string in to the database this can still be a advantage. Like
for systems that don't always know the exact day.
By representing them in String this can be overcome. Searches can be
done on year and month fairly easy. 

Met vriendelijke groet, 
Pieter Valentijn

Delphidreams
http://www.delphidreams.nl

-----Oorspronkelijk bericht-----
Van: michael <at> home.wisa.be [mailto:michael <at> home.wisa.be] Namens Michael
Van Canneyt
Verzonden: woensdag 28 februari 2007 22:49
Aan: lazarus <at> miraclec.com
Onderwerp: RE: [lazarus] StrToDate error

On Wed, 28 Feb 2007, Pieter Valentijn wrote:

> Most users here will find this kind of display confusing.
> But I agree with the store path. Anny external storae that needs sting
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pieter Valentijn | 1 Mar 11:39
Picon

RE: WikiHelp

This was my implementation of that routine

procedure TranslateUnitResourceStrings(const ResUnitName, BaseFilename,
  Lang, FallbackLang: string);
begin
  if (ResUnitName='') or (BaseFilename='') then exit;

  //debugln('TranslateUnitResourceStrings
BaseFilename="',BaseFilename,'"');
  if (FallbackLang<>'') then

DoTranslateUnitResourceStrings(ResUnitName,Format(BaseFilename,[Fallback
Lang]));
  if (Lang<>'') then

DoTranslateUnitResourceStrings(ResUnitName,Format(BaseFilename,[Lang]));
end;   

I did got it to work but I now have trouble getting the data. I think it
becouse you need to be loged in to go to the edit page.

index.php?title=Spezial:Export&action=submit&pages='+lbFoundPages.Items[
i]+'&curonly=true
This was you old line. If I follow the osF wiki I get a you are not
loged in message.
I gess we should be able to log in.

Met vriendelijke groet, 
Pieter Valentijn
(Continue reading)

Permalink | Reply | 8 comments |

Gmane