PDA

View Full Version : Strong objection to Compiler Error 16



Nick Wright
26-Sep-2005, 02:32 AM
I ran into this error today - Error 16 , invalid dates, because I entered
dates in the format dd/mm/yyyy into program source.

The arrogance of DAW is astonishing, why can't the compiler cope with non-US
format dates?

Does anyone else think that this is outrageous?

Nick

Anders Öhrt
26-Sep-2005, 02:49 AM
>I ran into this error today - Error 16 , invalid dates, because I entered
> dates in the format dd/mm/yyyy into program source.

Constant date in source is a problem, I'm not at all surprised you had
problems.


> The arrogance of DAW is astonishing, why can't the compiler cope with
> non-US format dates?

The arrogance is on your part IMO, designing a language is a complex issue
and a format must be picked. If you entered 01/02/2005, what should the
compiler use? 1st feb (your format) or 2nd jan (US)? It's impossible to
differentiate. And since DAW is US-based, choosing US as the format is
natural.

And it can't choose via locale, then your program would fail if compiled
with a different locale. _That_ I would find outragous.

// Anders

Nick Wright
26-Sep-2005, 04:44 AM
> Constant date in source is a problem, I'm not at all surprised you had
> problems.

When writing a one-off utility which updates data in a file based on
historical values it is common to write constant dates.
When entering a business rule which demarcates when a file format changed
(hence no historical data past that point) it is common to write constant
dates.


And it can't choose via locale, then your program would fail if compiled
> with a different locale. _That_ I would find outragous.
>


Agreed, setting the locale would be a stupid idea however that idea was not
suggested by me.

> The arrogance is on your part IMO, designing a language is a complex issue
> and a format must be picked.

Why must a format be picked by DAW? Granted have US-Locale as standard, but
allow the rest of the world to deviate - VDF can handle compiler directives.
Hard coding a format based on the locale of the author is not exactly what
is to be expected of an internationally distributed software package, and
the argument you made about using the locale in your program being
outrageous is the original point I was making!

Nick


"Anders Öhrt" <Anders.Ohrt@capslock.se> wrote in message
news:84YDD7mwFHA.3732@dacmail.dataaccess.com...
>
>>I ran into this error today - Error 16 , invalid dates, because I entered
>> dates in the format dd/mm/yyyy into program source.
>
> Constant date in source is a problem, I'm not at all surprised you had
> problems.
>
>
>> The arrogance of DAW is astonishing, why can't the compiler cope with
>> non-US format dates?
>
> The arrogance is on your part IMO, designing a language is a complex issue
> and a format must be picked. If you entered 01/02/2005, what should the
> compiler use? 1st feb (your format) or 2nd jan (US)? It's impossible to
> differentiate. And since DAW is US-based, choosing US as the format is
> natural.
>
> > // Anders
>
>

Anders Öhrt
26-Sep-2005, 05:52 AM
> Why must a format be picked by DAW? Granted have US-Locale as standard,
> but
> allow the rest of the world to deviate - VDF can handle compiler
> directives.

Compiler directives should be restricted to the base essentials, and this is
not something that's difficult to handle yourself.

We've written a simple function ClxDate that takes Y/M/D is our preferred
format. DAW could have provided something like this themselves maybe, but
beyond that I don't think they need to bother.

// Anders

Chris Spencer
26-Sep-2005, 06:15 AM
Nick

No because I know the VDF compiler uses US dates.

However I use the global function below in these situations. You probaly
have one similar.

// Returns a date from the pass dd mm yyyy in the correct format
//
Function ConstructDate Global integer iDay integer iMonth integer iYear
returns Date
DateTime dDate
Date dCurr
Move (CurrentDateTime()) To dDate
Move (DateSetDay (dDate, 1)) To dDate
Move (DateSetYear (dDate, iYear)) To dDate
Move (DateSetMonth (dDate, iMonth)) To dDate
Move (DateSetDay (dDate, iDay)) To dDate
Move dDate to dCurr
Function_Return dCurr
End_Function

Chris Spencer
TUFware Systems

"Nick Wright" <nwright@legend.com.au> wrote in message
news:LzFdHymwFHA.1276@dacmail.dataaccess.com...
>I ran into this error today - Error 16 , invalid dates, because I entered
>dates in the format dd/mm/yyyy into program source.
>
> The arrogance of DAW is astonishing, why can't the compiler cope with
> non-US format dates?
>
> Does anyone else think that this is outrageous?
>
> Nick
>

starzen
26-Sep-2005, 07:03 AM
Nick

if you where able to change date format in the compiler it would be a
nightmare. Think about sharing code across the world. Using third party
packages and such

Constant dates in code should simply not be used. Either get the dates via
functions or use a function to convert dates to the us date and use that
instead


--
Michael Salzlechner
StarZen Technologies, Inc
http://www.starzen.com
DataFlex Addon products, consulting

Nick Wright
26-Sep-2005, 07:11 AM
Ok, thanks all, must just be me, seems less important after a couple of
beers, I did my usual shoot from the hip, then think about what I said later
routine.

Cheers,
Nick.


"Nick Wright" <nwright@legend.com.au> wrote in message
news:LzFdHymwFHA.1276@dacmail.dataaccess.com...
>I ran into this error today - Error 16 , invalid dates, because I entered
>dates in the format dd/mm/yyyy into program source.
>
> The arrogance of DAW is astonishing, why can't the compiler cope with
> non-US format dates?
>
> Does anyone else think that this is outrageous?
>
> Nick
>

David Martinko
26-Sep-2005, 07:24 AM
Nick,

If you have noticed, DAW is very good at responding to developer requests. I
have a lot of great suggestions, but a few things I think of may become a
part of VDF. Your thread is a valid issue. It's not a bug, but a design
limitation. This would be something good to submit to DAW as a suggestion.
As you mentioned, perhaps compiler directives is the answer. It's just a
matter of starting a discussion, seeing how important it is to others, and
then submit to DAW.

--
David Martinko
Redeemed Software
248-535-7495
RedeemedSoftware(SHIFT+2)Hotmail(PERIOD)com
www.redeemedsoftware.com

"Nick Wright" <n.b.wright@btopenworld.com> wrote in message
news:Biz23NpwFHA.1276@dacmail.dataaccess.com...
> Ok, thanks all, must just be me, seems less important after a couple of
> beers, I did my usual shoot from the hip, then think about what I said
> later routine.
>
> Cheers,
> Nick.
>
>
> "Nick Wright" <nwright@legend.com.au> wrote in message
> news:LzFdHymwFHA.1276@dacmail.dataaccess.com...
>>I ran into this error today - Error 16 , invalid dates, because I entered
>>dates in the format dd/mm/yyyy into program source.
>>
>> The arrogance of DAW is astonishing, why can't the compiler cope with
>> non-US format dates?
>>
>> Does anyone else think that this is outrageous?
>>
>> Nick
>>
>
>

Evertjan Dondergoor
29-Sep-2005, 08:17 AM
Now you have cooled down a bit <g>, I also think the US-format is too confusing for a european guy like me. To me 04-27-2006 is a
invalid date and 03-04-2005 is the 3rd of april. Therefor I normally use the integer-representation and add the date as comment in
yyy-mm-dd format, so no confusing can arise.

Date dFarAway
Move 767024 To dFarAway // 2099-12-31
Showln dFarAway

Regards,
Evertjan


"Nick Wright" <n.b.wright@btopenworld.com> wrote in message news:Biz23NpwFHA.1276@dacmail.dataaccess.com...
> Ok, thanks all, must just be me, seems less important after a couple of beers, I did my usual shoot from the hip, then think about
> what I said later routine.
>
> Cheers,
> Nick.
>
>
> "Nick Wright" <nwright@legend.com.au> wrote in message news:LzFdHymwFHA.1276@dacmail.dataaccess.com...
>>I ran into this error today - Error 16 , invalid dates, because I entered dates in the format dd/mm/yyyy into program source.
>>
>> The arrogance of DAW is astonishing, why can't the compiler cope with non-US format dates?
>>
>> Does anyone else think that this is outrageous?
>>
>> Nick
>>
>
>

Peager
29-Sep-2005, 01:33 PM
I appreciate the problems this causes for you guys but as one of the
'minority' US users, I've often thought about how one would truly make an
app 'locally' applicable. It would seem to me that with the new data types
we should be able to build a function that would be called something like
this: USDate(10,30,2005) or EroDate(2005,10,30) or....
Then our source code is more self documenting....

Paul

--
Paul E. Richmond
IS Project Leader
L.D. McFarland Co.
(253) 572-3033
"Evertjan Dondergoor" <evertjan.dondergoor@dataaccess.nl> wrote in message
news:jAdUngPxFHA.3452@dacmail.dataaccess.com...
> Now you have cooled down a bit <g>, I also think the US-format is too
> confusing for a european guy like me. To me 04-27-2006 is a invalid date
> and 03-04-2005 is the 3rd of april. Therefor I normally use the
> integer-representation and add the date as comment in yyy-mm-dd format, so
> no confusing can arise.
>
> Date dFarAway
> Move 767024 To dFarAway // 2099-12-31
> Showln dFarAway
>
> Regards,
> Evertjan
>
>
> "Nick Wright" <n.b.wright@btopenworld.com> wrote in message
> news:Biz23NpwFHA.1276@dacmail.dataaccess.com...
>> Ok, thanks all, must just be me, seems less important after a couple of
>> beers, I did my usual shoot from the hip, then think about what I said
>> later routine.
>>
>> Cheers,
>> Nick.
>>
>>
>> "Nick Wright" <nwright@legend.com.au> wrote in message
>> news:LzFdHymwFHA.1276@dacmail.dataaccess.com...
>>>I ran into this error today - Error 16 , invalid dates, because I entered
>>>dates in the format dd/mm/yyyy into program source.
>>>
>>> The arrogance of DAW is astonishing, why can't the compiler cope with
>>> non-US format dates?
>>>
>>> Does anyone else think that this is outrageous?
>>>
>>> Nick
>>>
>>
>>
>
>

Garret Mott
29-Sep-2005, 01:50 PM
We could always get with the rest of the world:

Dates: Smallest, next smallest, biggest (day, month, year) Hmmm... that
even makes sense!
Time: 24 hour - but then letter manufacturers wouldn't sell as many p's, a's
& m's - they would sell more colons though...
Measurement: Use a system in base 10 - of course base 12 is so much
easier...? + a pint of beer sounds so much better than half-liter! Not to
mention easier to say after 5 or 6.

It seems to me that there could be a compiler switch that specified how
dates are written:

-U 01/30/2005 (U=US)
-R 30/01/2005 (R=Rest of the world)

This would require documentation in code though - I see 03/04 as Mar. 4, you
see it as Apr. 3 - could be a real mess.

Get back to work, Garret



"Paul E. Richmond" <paulr@ldm.com> wrote in message
news:sGtVHRSxFHA.2208@dacmail.dataaccess.com...
>I appreciate the problems this causes for you guys but as one of the
>'minority' US users, I've often thought about how one would truly make an
>app 'locally' applicable. It would seem to me that with the new data types
>we should be able to build a function that would be called something like
>this: USDate(10,30,2005) or EroDate(2005,10,30) or....
> Then our source code is more self documenting....
>
> Paul
>
> --
> Paul E. Richmond
> IS Project Leader
> L.D. McFarland Co.
> (253) 572-3033
> "Evertjan Dondergoor" <evertjan.dondergoor@dataaccess.nl> wrote in message
> news:jAdUngPxFHA.3452@dacmail.dataaccess.com...
>> Now you have cooled down a bit <g>, I also think the US-format is too
>> confusing for a european guy like me. To me 04-27-2006 is a invalid date
>> and 03-04-2005 is the 3rd of april. Therefor I normally use the
>> integer-representation and add the date as comment in yyy-mm-dd format,
>> so no confusing can arise.
>>
>> Date dFarAway
>> Move 767024 To dFarAway // 2099-12-31
>> Showln dFarAway
>>
>> Regards,
>> Evertjan
>>
>>
>> "Nick Wright" <n.b.wright@btopenworld.com> wrote in message
>> news:Biz23NpwFHA.1276@dacmail.dataaccess.com...
>>> Ok, thanks all, must just be me, seems less important after a couple of
>>> beers, I did my usual shoot from the hip, then think about what I said
>>> later routine.
>>>
>>> Cheers,
>>> Nick.
>>>
>>>
>>> "Nick Wright" <nwright@legend.com.au> wrote in message
>>> news:LzFdHymwFHA.1276@dacmail.dataaccess.com...
>>>>I ran into this error today - Error 16 , invalid dates, because I
>>>>entered dates in the format dd/mm/yyyy into program source.
>>>>
>>>> The arrogance of DAW is astonishing, why can't the compiler cope with
>>>> non-US format dates?
>>>>
>>>> Does anyone else think that this is outrageous?
>>>>
>>>> Nick
>>>>
>>>
>>>
>>
>>
>
>

Erik Zimmerman
29-Sep-2005, 02:08 PM
Garrett,

It really seems like you have too much time on your hands. LOL. Although, I
must say that sometimes the humor in this NG is almost as good as the help.

Erik

"Garret Mott" <garret_atsign_automatesoftware_dot_com> wrote in message
news:tR%23vzaSxFHA.2172@dacmail.dataaccess.com...
> We could always get with the rest of the world:
>
> Dates: Smallest, next smallest, biggest (day, month, year) Hmmm... that
> even makes sense!
> Time: 24 hour - but then letter manufacturers wouldn't sell as many p's,
a's
> & m's - they would sell more colons though...
> Measurement: Use a system in base 10 - of course base 12 is so much
> easier...? + a pint of beer sounds so much better than half-liter! Not
to
> mention easier to say after 5 or 6.
>
> It seems to me that there could be a compiler switch that specified how
> dates are written:
>
> -U 01/30/2005 (U=US)
> -R 30/01/2005 (R=Rest of the world)
>
> This would require documentation in code though - I see 03/04 as Mar. 4,
you
> see it as Apr. 3 - could be a real mess.
>
> Get back to work, Garret
>
>
>
> "Paul E. Richmond" <paulr@ldm.com> wrote in message
> news:sGtVHRSxFHA.2208@dacmail.dataaccess.com...
> >I appreciate the problems this causes for you guys but as one of the
> >'minority' US users, I've often thought about how one would truly make an
> >app 'locally' applicable. It would seem to me that with the new data
types
> >we should be able to build a function that would be called something like
> >this: USDate(10,30,2005) or EroDate(2005,10,30) or....
> > Then our source code is more self documenting....
> >
> > Paul
> >
> > --
> > Paul E. Richmond
> > IS Project Leader
> > L.D. McFarland Co.
> > (253) 572-3033
> > "Evertjan Dondergoor" <evertjan.dondergoor@dataaccess.nl> wrote in
message
> > news:jAdUngPxFHA.3452@dacmail.dataaccess.com...
> >> Now you have cooled down a bit <g>, I also think the US-format is too
> >> confusing for a european guy like me. To me 04-27-2006 is a invalid
date
> >> and 03-04-2005 is the 3rd of april. Therefor I normally use the
> >> integer-representation and add the date as comment in yyy-mm-dd format,
> >> so no confusing can arise.
> >>
> >> Date dFarAway
> >> Move 767024 To dFarAway // 2099-12-31
> >> Showln dFarAway
> >>
> >> Regards,
> >> Evertjan
> >>
> >>
> >> "Nick Wright" <n.b.wright@btopenworld.com> wrote in message
> >> news:Biz23NpwFHA.1276@dacmail.dataaccess.com...
> >>> Ok, thanks all, must just be me, seems less important after a couple
of
> >>> beers, I did my usual shoot from the hip, then think about what I said
> >>> later routine.
> >>>
> >>> Cheers,
> >>> Nick.
> >>>
> >>>
> >>> "Nick Wright" <nwright@legend.com.au> wrote in message
> >>> news:LzFdHymwFHA.1276@dacmail.dataaccess.com...
> >>>>I ran into this error today - Error 16 , invalid dates, because I
> >>>>entered dates in the format dd/mm/yyyy into program source.
> >>>>
> >>>> The arrogance of DAW is astonishing, why can't the compiler cope with
> >>>> non-US format dates?
> >>>>
> >>>> Does anyone else think that this is outrageous?
> >>>>
> >>>> Nick
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>

Garret Mott
29-Sep-2005, 02:23 PM
But not this time, right? <g>

I really don't have enough time- I'm just working on something that's making
me a little crazy (crazier?), so I need a break every now & then & it's not
beer:30 yet... Now there's a time that translates the world over!

Garret

"Erik Zimmerman" <erikz@compadmin.com> wrote in message
news:vkkG8kSxFHA.2248@dacmail.dataaccess.com...
> Garrett,
>
> It really seems like you have too much time on your hands. LOL. Although,
> I
> must say that sometimes the humor in this NG is almost as good as the
> help.
>
> Erik
>
> "Garret Mott" <garret_atsign_automatesoftware_dot_com> wrote in message
> news:tR%23vzaSxFHA.2172@dacmail.dataaccess.com...
>> We could always get with the rest of the world:
>>
>> Dates: Smallest, next smallest, biggest (day, month, year) Hmmm... that
>> even makes sense!
>> Time: 24 hour - but then letter manufacturers wouldn't sell as many p's,
> a's
>> & m's - they would sell more colons though...
>> Measurement: Use a system in base 10 - of course base 12 is so much
>> easier...? + a pint of beer sounds so much better than half-liter! Not
> to
>> mention easier to say after 5 or 6.
>>
>> It seems to me that there could be a compiler switch that specified how
>> dates are written:
>>
>> -U 01/30/2005 (U=US)
>> -R 30/01/2005 (R=Rest of the world)
>>
>> This would require documentation in code though - I see 03/04 as Mar. 4,
> you
>> see it as Apr. 3 - could be a real mess.
>>
>> Get back to work, Garret
>>
>>
>>
>> "Paul E. Richmond" <paulr@ldm.com> wrote in message
>> news:sGtVHRSxFHA.2208@dacmail.dataaccess.com...
>> >I appreciate the problems this causes for you guys but as one of the
>> >'minority' US users, I've often thought about how one would truly make
>> >an
>> >app 'locally' applicable. It would seem to me that with the new data
> types
>> >we should be able to build a function that would be called something
>> >like
>> >this: USDate(10,30,2005) or EroDate(2005,10,30) or....
>> > Then our source code is more self documenting....
>> >
>> > Paul
>> >
>> > --
>> > Paul E. Richmond
>> > IS Project Leader
>> > L.D. McFarland Co.
>> > (253) 572-3033
>> > "Evertjan Dondergoor" <evertjan.dondergoor@dataaccess.nl> wrote in
> message
>> > news:jAdUngPxFHA.3452@dacmail.dataaccess.com...
>> >> Now you have cooled down a bit <g>, I also think the US-format is too
>> >> confusing for a european guy like me. To me 04-27-2006 is a invalid
> date
>> >> and 03-04-2005 is the 3rd of april. Therefor I normally use the
>> >> integer-representation and add the date as comment in yyy-mm-dd
>> >> format,
>> >> so no confusing can arise.
>> >>
>> >> Date dFarAway
>> >> Move 767024 To dFarAway // 2099-12-31
>> >> Showln dFarAway
>> >>
>> >> Regards,
>> >> Evertjan
>> >>
>> >>
>> >> "Nick Wright" <n.b.wright@btopenworld.com> wrote in message
>> >> news:Biz23NpwFHA.1276@dacmail.dataaccess.com...
>> >>> Ok, thanks all, must just be me, seems less important after a couple
> of
>> >>> beers, I did my usual shoot from the hip, then think about what I
>> >>> said
>> >>> later routine.
>> >>>
>> >>> Cheers,
>> >>> Nick.
>> >>>
>> >>>
>> >>> "Nick Wright" <nwright@legend.com.au> wrote in message
>> >>> news:LzFdHymwFHA.1276@dacmail.dataaccess.com...
>> >>>>I ran into this error today - Error 16 , invalid dates, because I
>> >>>>entered dates in the format dd/mm/yyyy into program source.
>> >>>>
>> >>>> The arrogance of DAW is astonishing, why can't the compiler cope
>> >>>> with
>> >>>> non-US format dates?
>> >>>>
>> >>>> Does anyone else think that this is outrageous?
>> >>>>
>> >>>> Nick
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>
>

Marco
29-Sep-2005, 10:15 PM
The iso date format of today is '2005-09-30'

I guess the safest would be to always convert back to iso, do your stuff
then move back...

Cheers,
Marco

Paul E. Richmond wrote:
> I appreciate the problems this causes for you guys but as one of the
> 'minority' US users, I've often thought about how one would truly make an
> app 'locally' applicable. It would seem to me that with the new data types
> we should be able to build a function that would be called something like
> this: USDate(10,30,2005) or EroDate(2005,10,30) or....
> Then our source code is more self documenting....
>
> Paul
>