Date Conversion in Pick Basic
Robert Marik
Ending.Date. I then wish to Select some records for the period one year
before these dates for compartative reasons. If the Start.Date is 8.15 then
I wish to convert it to the prior year or 8.15.2001 and also save the
internal date. I could just prompt for the prior year's date but wish to
simplify it for data entry.
My current procedure is to convert the entered date to internal ;
START.INT.DATE = ICONV(START.DATE, 'D'); then convert to an external date ;
START.EXT.DATE = OCONV(START.INT.DATE,'D4'); and then to subtract 1 from the
year; YEAR = START.EXT.DATE[8,4] - 1; and finally START.DATE =
START.EXT.DATE[1,7]:YEAR
I'm sure there must be a better way to do this. Any suggestions??
Thanks for your help
Bob Marik
Ron Black
start.int.date = iconv(start.date,'d') -365.25
something like that should get you the internal pick date for the year you
are looking for.
"Robert Marik" <rma...@mcbaincamera.com> wrote in message
news:j2i19.65417$v53.2...@news3.calgary.shaw.ca...
David Knight
I'm certain others can come up with more 'elegant' and 'code-efficient'
methods than I; but I want to make two points:
1. What is the defininition of '1 year earlier'? I know that sounds stupid;
but it does matter. eg: If this year is a leap year, and they enter 29 Feb,
then there is no 29 Feb of the previous year. So is the definition of a
prior year minus 365 days, minus 1 from the CCYY component of the date, or
what?
2. I would not use text extraction methods. That's what got the rest of the
world the y2k bug. Use a date ICONV to grab the CCYY part for you, as that
will *always* work despite changes in data formats or lengths for unforseen
reasons. Or work with the internal date and subtract 365 days.
Just my 2c worth.
David
"Robert Marik" <rma...@mcbaincamera.com> wrote in message
news:j2i19.65417$v53.2...@news3.calgary.shaw.ca...
Richard A. Wilson
add is leap year logic so if 2-29 entered then back off to
2-28 or 2-28 entered back off to 2-29 where appropriate
Rich
--
Richard A. Wilson
Lakeside Systems
Smithfield, RI, USA
terry...@yahoo.com
> I am writing a small basic program which prompts for a Start.Date and an
> Ending.Date.
>
> My current procedure is to convert the entered date to internal ;
> START.INT.DATE = ICONV(START.DATE, 'D'); then convert to an external date ;
> START.EXT.DATE = OCONV(START.INT.DATE,'D4'); and then to subtract 1 from the
> year; YEAR = START.EXT.DATE[8,4] - 1; and finally START.DATE =
> START.EXT.DATE[1,7]:YEAR
>
Don't forget to make sure the prior year's date does exist (Feb 29th.)
Here's a way to do it quickly.
EQU AM TO CHAR(254)
START.INT.DATE = ICONV(START.DATE, 'D')
IF START.INT.DATE = '' THEN
* do error handling
END ELSE
START.EXT.DATE = OCONV(START.INT.DATE, 'D':AM)
#
IF START.EXT.DATE<1> = 2 AND START.EXT.DATE<2> = 29 THEN
START.EXT.DATE<2> = 28
END
START.EXT.DATE<3> -= 1
#
CONVERT AM TO '/' IN EXT.DATE
END
--
Terry Layne
Portland, OR
terry...@yahoo.com
> Don't forget to make sure the prior year's date does exist (Feb 29th.)
> Here's a way to do it quickly.
>
> EQU AM TO CHAR(254)
>
> START.INT.DATE = ICONV(START.DATE, 'D')
>
> IF START.INT.DATE = '' THEN
> * do error handling
> END ELSE
> START.EXT.DATE = OCONV(START.INT.DATE, 'D':AM)
> #
> IF START.EXT.DATE<1> = 2 AND START.EXT.DATE<2> = 29 THEN
> START.EXT.DATE<2> = 28
> END
> START.EXT.DATE<3> -= 1
> #
> CONVERT AM TO '/' IN EXT.DATE
Oops, should have compiled my email first!
That last line should have been:
CONVERT AM TO '/' IN START.EXT.DATE
> END
>
Improving the Feb 29th logic is left as an exercise.
I must admit, using the AM to turn the external date into
a dynamic array is probably too cute for production use.
I just miss the "split" and "join" syntax from Perl.
Robert Herbin
and ONE.YEAR.AGO are internal dates):
CURR.YEAR = OCONV(START.DATE,'DY')
LEAP.DATE = ICONV('2-29-':CURR.YEAR,'D') ; * will evaluate to null if this
is not a leap year
ONE.YEAR.AGO = START.DATE - 365 - ('X':LEAP.DATE # 'X') ; * test for null,
not zero, zero is a valid date!
I came up with a few other versions, but I liked this one best.
Robert Herbin
"Robert Marik" <rma...@mcbaincamera.com> wrote in message
news:j2i19.65417$v53.2...@news3.calgary.shaw.ca...
CWNoah2
This is how I do it.
START.DATE = ICONV(START.DATE, 'D')
START.DATE.LAST.YEAR = ICONV(OCONV(START.DATE, 'DM'): '-':
OCONV(START.DATE, 'DD'): '-': OCONV(START.DATE, 'D4Y') - 1, 'D')
*
* If start date is leap day, it will return null. If 03-01 is desired, use the
+1 below,
* if now, leave the +1 off
*
IF START.DATE.LAST.YEAR = '' THEN
START.DATE.LAST.YEAR = ICONV(OCONV(START.DATE, 'DM'): '-':
OCONV(START.DATE, 'DD') - 1: '-': OCONV(START.DATE, 'D4Y') - 1, 'D') + 1
END
I keep all dates in memory in internal format, and OCONV when needed.
Regards,
Charlie Noah
"Robert Marik" <rma...@mcbaincamera.com> writes:
Charlie Noah (CWN...@aol.com)
Robert Marik
the coding for converting to 1 year earlier. I had considered the -365
solution but decided that leap year would be a problem so the solutions that
correct for the leap year should answer my question. Thanks again for the
replies.
Bob Marik
"Robert Marik" <rma...@mcbaincamera.com> wrote in message
news:j2i19.65417$v53.2...@news3.calgary.shaw.ca...
neilcharrington
in the year calculation?
Shouldn't the [8,4] be [7,4] and the [1,7] be [1,6]?
An OCONV will create either "dd/mm/yyyy" or "mm/dd/yyyy" (depending on the
date format) and therefore the yyyy starts at position 7 not 8.
Neil Charrington.
"Robert Marik" <rma...@mcbaincamera.com> wrote in message
news:j2i19.65417$v53.2...@news3.calgary.shaw.ca...
K. Powick
news:3d47cb2d$0$234$cc9e...@news.dial.pipex.com...
> Am I missing something here or is there a reason for you missing the century
> in the year calculation?
>
> Shouldn't the [8,4] be [7,4] and the [1,7] be [1,6]?
>
> An OCONV will create either "dd/mm/yyyy" or "mm/dd/yyyy" (depending on the
> date format) and therefore the yyyy starts at position 7 not 8.
You are correct if you use OCONV "D4/", but Robert M. is not using the "/" character,
so his code is correct.
OCONV D4 = " dd mmm yyyy" year starts at 8
K. Powick
> "Robert Marik" <rma...@mcbaincamera.com> wrote in message
> > My current procedure is to convert the entered date to internal ;
neilcharrington
"K. Powick" <nos...@nospam.com> wrote in message
news:aqR19.4302$tY5.1...@news20.bellglobal.com...
Hal Henderson
--
Hal Henderson
Total Computing Solutions
"neilcharrington" <ne...@casoftware.co.uk> wrote in message
news:3d47edcb$0$231$cc9e...@news.dial.pipex.com...
Jeffrey Kaufman
"Hal Henderson" <H...@Total-Computing.com> wrote in message
news:aic75k$s4h$1...@terabinaries.xmission.com...
> Isn't anyone here concerned about Y10K?
>
> --
> Hal Henderson
> Total Computing Solutions
I'm going to procrastinate.
BobJ
to it".
BobJ
"Jeffrey Kaufman" <jkau...@keydat.com> wrote in message
news:yYj29.117149$uh7.18890@sccrnsc03...
JPORSHA924
a totally invalid date and miss formed date.
2/29/01 would return the internal date of 3/1/01. if would always verify dates
by comparing the oconv of the iconv of the input to the original.
onto y10k
CWNoah2
Regards,
Charlie Noah
jpors...@aol.com (JPORSHA924) writes:
Charlie Noah (CWN...@aol.com)
noone
probably won't be read by anyone, but here goes anyway...
The problem with externalising dates is the whole reason that Pick uses an
internal format! In the US, external dates are in MM/DD/YYYY format, whereas
in the UK, external dates are in DD/MM/YYY format.
To complicate matters even more, in Sweden they use YYYY/MM/DD format!!! If
you want to write generic code (and don't we all)?, that will run on any
server, irrespective of the date format, then it is important to know what
that date format is.
As far as I know, there isn't a system call that returns the external date
format (?????), but it can be done with a few lines of coding.
What we do is take a non-ambiguous external date - for example 01/02/03 is
ambiguous because each 2 digit number could be a year, a month or a day.
However, 31/12/2002 is unambiguous.
We then do an ICONV of the different permutations of this externalised date
until we get a non-null answer. In otherwords, which of the 3 strings
31/12/2002
12/31/2002
2002/12/31
returns a valid internal date when ICONVed?
Once we've determined this, we can then manipulate externalised dates.
Remember, it's easy to extract the day, month or year from a date by using
the 'DD', 'DM' or 'DY' conversion, but once we then try to manipulate these
and put together an internalised externalised (sic) date, that's where our
problems really start.
As for the year 10k, I'm personally looking forward to it...
"Robert Marik" <rma...@mcbaincamera.com> wrote in message
news:j2i19.65417$v53.2...@news3.calgary.shaw.ca...
Mecki Forthmann
"noone" <no...@anywhere.com> wrote in message
news:3d5a06bd$0$91282$45be...@newscene.com...
> I've probably come into this conversation a bit late, which means that it
> probably won't be read by anyone, but here goes anyway...
>
> The problem with externalising dates is the whole reason that Pick uses an
> internal format! In the US, external dates are in MM/DD/YYYY format,
whereas
> in the UK, external dates are in DD/MM/YYY format.
>
Year.
I don't say DD/MM/YYYY on purpose since 1.2.02 is a valid date, and that's
how most people will write it.
IMO the most logical form to represent dates since it comes closest to the
way we think and speak.
You don't usually mention the month if the day refers to the current month
in a conversation.
Pick even allows you to omit the year and will automatically assume the
current year.
The 3 digit year used in the UK is news to me, though.
Now that things have gone back to normal after the Y2K hype, 2 digit years
are used more and more again.
> To complicate matters even more, in Sweden they use YYYY/MM/DD format!!!
If
> you want to write generic code (and don't we all)?, that will run on any
> server, irrespective of the date format, then it is important to know what
> that date format is.
>
Strange really since Sweden is the only country that changed from driving on
the left hand side to the right to comply with the rest of continental
Europe.
Nevertheless Pick only supports 2 formats the US (they would call that
standard of course) and the international.
> As far as I know, there isn't a system call that returns the external date
> format (?????), but it can be done with a few lines of coding.
>
> What we do is take a non-ambiguous external date - for example 01/02/03 is
> ambiguous because each 2 digit number could be a year, a month or a day.
> However, 31/12/2002 is unambiguous.
>
> We then do an ICONV of the different permutations of this externalised
date
> until we get a non-null answer. In otherwords, which of the 3 strings
>
> 31/12/2002
> 12/31/2002
> 2002/12/31
>
> returns a valid internal date when ICONVed?
>
> Once we've determined this, we can then manipulate externalised dates.
>
Wouldn't it be easier to just OCONV a known date?
IF FIELD(OCONV(0,'D2/'),'/',1) = 31 THEN DATE.FORMAT='IN' ELSE
DATE.FORMAT='US'
We all know that the internal date 0 = 31 Dec 1967.
IMO we don't need a function or system call to determine this, since writing
this one line of code should be easy for any programmer.
But what I find a lot more difficult is to deal with servers that get
accessed by users in the US and countries with international date format.
You either force all users to use the same date input format, which is IMO
rather (c)rude, or you have to write a routine that converts date inputs
from international to US or vice versa depending on the user's preferences.
This is where IMHO a functionality in ICONV and OCONV is missing.
OTOH it would be great if you could set the date format by port like you can
in Unidata instead having it fixed for the server like D3.
> Remember, it's easy to extract the day, month or year from a date by using
> the 'DD', 'DM' or 'DY' conversion, but once we then try to manipulate
these
> and put together an internalised externalised (sic) date, that's where our
> problems really start.
>
That's why I reckon we need an option in ICONV to convert international or
US dates into internal format regardless what format the server is set for.
So if you would say ICONV('2/1/68','DI') it would always return 2 regardless
of the server using US date format.
You could set the preferred date format at login and pass it in a named
common or a control file item to all relevant programs for instance.
And of course, if the US would decide to follow the standards used by the
majority of the world for a change we wouldn't have this problem.;^)
> As for the year 10k, I'm personally looking forward to it...
I think it will be less of a problem than Y2K.
I don't think that anyone would confuse 0001 with 1 AD.
And we will calculate dates by Stardate by then anyway ;^).
noone
just missed off a letter Y!!!
I worked on some software for a Swedish company once, in a UNIDATA/SB+
environment, and we did get the system to recognise the Swedish YYYY/MM/DD
format, so it's not just a case of saying it's either US or International. I
do get your point about using a known date, but we'd have to test for 3
different positions for the 31.
I wonder if there's a country somewhere in the world perverse enough to
write their dates as MM/YYYY/DD or DD/YYYY/MM? Highly unlikely, but I
suppose if we wanted to be really pedantic we could check for all 6
permutations of day, month and year!!!
aha...but do you know why the Swedish went from driving on the left to
driving on the right? It was nothing to do with conformity...it was to do
with the fact that at the time a lot of cars in Sweden were german imports,
so it made sense to drive on the same side of the road as the Germans,
rather than having to convert the cars or drive with the steering wheel on
the wrong side.
You learn something new every day, don't you?
:-)
"Mecki Forthmann" <mec...@hotmail.com> wrote in message
news:0Lp69.217$XA1....@newsfep1-gui.server.ntli.net...
Mecki Forthmann
> erm...sorry I mis-typed originally. We don't use 3 digit years in the UK,
I
> just missed off a letter Y!!!
>
> I worked on some software for a Swedish company once, in a UNIDATA/SB+
> environment, and we did get the system to recognise the Swedish YYYY/MM/DD
> format, so it's not just a case of saying it's either US or International.
I
> do get your point about using a known date, but we'd have to test for 3
> different positions for the 31.
>
The internal date 0 is the 31 Dec 1967, so if you OCONV(0,'D4/') you only
have to look at the first field delimited by /.
In your case (Swedish) it would be 1967 (that is if Unidata can actually use
a mask for date format), in international format it would always be 31 and
in US format it would be 12.
> I wonder if there's a country somewhere in the world perverse enough to
> write their dates as MM/YYYY/DD or DD/YYYY/MM? Highly unlikely, but I
> suppose if we wanted to be really pedantic we could check for all 6
> permutations of day, month and year!!!
>
Same thing here - the OCONV method will always return the same 3 numbers
31,12 and 1967 delimited by /.
31 is always the day, 12 the month and 1967 the year.
All you have to do is analyse the 3 fields.
TDATE = OCONV(0,'D4/') ;* TDATE will always be the external numeric
representation of 31 Dec 1967 depending on system settings
BEGIN CASE
CASE TDATE MATCHES "2N'/'2N'/'4N"
* TDATE equals 31/12/1967 or 12/31/1967 - international or US
format
IF FIELD(TDATE,'/',1) = 12 THEN DATE.FORMAT=US' ELSE DATE.FORMAT
= 'IN'
CASE TDATE MATCHES "4N'/'2N'/'2N"
* 1967/12/31 or 1967/31/12 - Swedish or other format with year
first
IF FIELD(TDATE,'/',2) = 12 THEN DATE.FORMAT= 'SW' ELSE
DATE.FORMAT = 'YYYY/DD/MM'
CASE 1
* 12/1967/31 or 31/1967/12 other weird formats
IF FIELD(TDATE,'/',1) = 12 THEN DATE.FORMAT = 'MM/YYYY/DD' ELSE
DATE.FORMAT = 'DD/YYYY/MM'
END CASE
> aha...but do you know why the Swedish went from driving on the left to
> driving on the right? It was nothing to do with conformity...it was to do
> with the fact that at the time a lot of cars in Sweden were german
imports,
> so it made sense to drive on the same side of the road as the Germans,
> rather than having to convert the cars or drive with the steering wheel on
> the wrong side.
>
German car makers have for some time now produced cars with right hand
steering for the British market, so I don't know if that was really the
reason or to get in line with Denmark and Norway or lower production costs
for Volvos and Saabs with left hand steering or...?
BTW do you know why the British drive on the left?
From what I heard it is because Napoleon decreed that all traffic should
keep to the right hand side of the road to ease traffic congestion in Paris.
Since France was their arch-enemy, the English decided to do just the
opposite as the French and drive on the other side of the road.
Mecki
<snip>
noone
Mecki,
no I didn't know why the British drove on the left...could be plausible that
we did it just to be different from the French.
back to date conversions...
did you know there used to be a very basic problem with date conversions in
Pick? I discovered this round about 1985, but I think it has since been
fixed.
The way most date validations work is to do an ICONV of an external date; if
the ICONVed date is null, then a date is rejected as invalid.
The bug I discovered was as follows...if you entered an otherwise correct
date, but prefixed with a special character, such as [ or ( etc, then the
ICONV wouldn't convert to null, but would convert to an internal date
prefixed with the character.
For example, today is15/8. If you do X=ICONV('15/8','D') this gives 12646.
If you do X=ICONV('[15/8','D') this gives a null value, since [15/8 is not a
valid date. However, way back when, what seemed to happen is that Pick
recognised the 15/8 portion as being a valid date, so converted the [15/8 to
[12646.
I discovered this when looking at some software that had been written by
another company. A user kept getting "non-numeric when numeric required"
error message. This was because the software in question validated dates as
above; ICONV the date and then check the ICONVed value for null. Since it
wasn't null, it was allowing the user to enter [15/8 as a date and hence
they were ending up with an invalid internal date. When you tried to do
something like add 30 to it, you got the error message.
Of course nowadays bugs like that have been ironed out...hopefully!!
BobJ
WWII, so that is probably not the reason.
BobJnews:3d5b5d74$0$5262$45be...@newscene.com...
Mecki Forthmann
See http://www.2pass.co.uk/goodluck.htm
So according to this it's not to spite the French but the fact that Napoleon
didn't manage to cross the channel.
But then this is a British website ;^).
Mecki
"BobJ" <b...@rjoslyn.com> wrote in message
news:ajgr72$60$1...@slb1.atl.mindspring.net...
Anthony W. Youngman
Forthmann <mec...@hotmail.com> writes
>German car makers have for some time now produced cars with right hand
>steering for the British market, so I don't know if that was really the
>reason or to get in line with Denmark and Norway or lower production costs
>for Volvos and Saabs with left hand steering or...?
>BTW do you know why the British drive on the left?
>From what I heard it is because Napoleon decreed that all traffic should
>keep to the right hand side of the road to ease traffic congestion in Paris.
>Since France was their arch-enemy, the English decided to do just the
>opposite as the French and drive on the other side of the road.
I've heard various stories too. The main one I've always believed is
that rich people always pass "right to right" ie on the left because
that is their sword hand. After the revolution nobody in France wanted
to be thought noble/rich so they passed left-to-left. Napoleon then
exported this to the rest of Europe.
The other story I came across recently was how a coachman handled a
multi-horse team. Similar reasons, in one country the coachman sat on
the coach, in the other he sat on a horse. Both made passing on one side
easier than the other. With the horses you wanted the mounted horses
next to each other, and the riderless horse by the side of the road.
Can't remember the argument for the guy on the coach.
Cheers,
Wol.
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
Witches are curious by definition and inquisitive by nature. She moved in. "Let
me through. I'm a nosey person.", she said, employing both elbows.
Maskerade : (c) 1995 Terry Pratchett
Anthony W. Youngman
<no...@anywhere.com> writes
>I've probably come into this conversation a bit late, which means that it
>probably won't be read by anyone, but here goes anyway...
>
>The problem with externalising dates is the whole reason that Pick uses an
>internal format! In the US, external dates are in MM/DD/YYYY format, whereas
>in the UK, external dates are in DD/MM/YYY format.
>
>To complicate matters even more, in Sweden they use YYYY/MM/DD format!!!
Which is the ISO standard, and the only way of sorting dates
correctly...
> If
>you want to write generic code (and don't we all)?, that will run on any
>server, irrespective of the date format, then it is important to know what
>that date format is.
>
>As far as I know, there isn't a system call that returns the external date
>format (?????), but it can be done with a few lines of coding.
>
>What we do is take a non-ambiguous external date - for example 01/02/03 is
>ambiguous because each 2 digit number could be a year, a month or a day.
>However, 31/12/2002 is unambiguous.
>
>We then do an ICONV of the different permutations of this externalised date
>until we get a non-null answer. In otherwords, which of the 3 strings
>
>31/12/2002
>12/31/2002
>2002/12/31
>
>returns a valid internal date when ICONVed?
WATCH OUT !!! In INFORMATION certainly, and therefore presumably in U2
at least, all three variants will return the same result, the correct
value for 31st Dec 02. The default is used to output, and to *clarify*
ambiguity on input.
>
>Once we've determined this, we can then manipulate externalised dates.
>
Your technique won't work on the clones ...
As to your other comment about duff characters, whereas Pick returns ""
when fed an invalid date (or so I understand that's what the manual
says), PI returns the original string unchanged - as documented per the
manual.
Cheers,
Wol
Brett Callacher
Would love to know the true reason for this. The story I have heard is
similar to yours, that is that driving on the left is a throwback to
mounting a horse, with a scabbard on the left (for a right handed
swordsman), is much easier from the left - and it is safer to mount a horse
from the side of the road! This would also perhaps explain the same
practice in Japan? I think the French revolution idea is believable for
explaining the opposite practice.
Cheers
Brett
"Anthony W. Youngman" <thew...@nospam.demon.co.uk> wrote in message
news:2N8q4iA4...@thewolery.demon.co.uk...