Trying to create an auto field that gives todays date +28 days?

[Guest]

Hey all,
I use Word97. I'm trying to create an auto update field that shows the
print date + 28 days in 'day, date month year' format in a letter.
The field code for the print date is: { PRINTDATE \@ "dddd, dd MMMM yyyy"
\* MERGEFORMAT }
I've experimented with a couple of things, but had no glory at all.
Cheers
Tony

 

[Jezebel]

Unfortunately, Word doesn't provide a simple field-based way to do date
arithmetic. If you've got nothing better to do and yoru document has no
legal significance, you can experiment Macropod's hilarious field
calculations (do a Google); but if the requirement is anything serious,
you'll need to use a macro.

 

[garfield-n-odie [MVP]]

See http://www.gmayor.com/insert_a_date_other_than_today.htm .

 

[Graham Mayor]

How do you think a date inserted by macro or even typed from the keyboard
would have greater legal significance than one inserted by a field
calculation?

--
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor - Word MVP

My web site www.gmayor.com

<>>< ><<> ><<> <>>< ><<> <>>< <>><<>

 

[Jezebel]

I think it would be irresponsible, in a formal application, to rely on a
field calculation of the Macropod sort. Those field sequences (converting to
Julian number and back) are technically -- ie, in the audit sense --
'complex calculations' of the sort that requires, in any situation subject
to audit, formally documented validation. These is easily provided for
macro code -- particularly for code as trivial as adding 28 to a date; it is
not easily provided for a nested field calculation that runs to more than
300 characters and five levels of nesting.

 

[Graham Mayor]

I have no argument that macro's are simpler (maybe not so simple in a mail
merge) - but you brought up 'legal significance' and there is none. The
field constructions may be complex, but they work (and in the final analysis
that is all that matters), and all the donkey work has already been done.

--
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor - Word MVP

My web site www.gmayor.com

<>>< ><<> ><<> <>>< ><<> <>>< <>><<>

 

[Jezebel]

The assertion that those field calculations "work" is questionable. They
certainly work *sometimes* -- but it's not easy to prove it -- which an
auditor is entitled to ask you to do.

Clearly some correspondence has legal significance -- particularly letters
with statements like "do such-and-such within 28 days of the date of this
letter". As a matter of practical corporate goverance, obviously you can't
check every single calculation in every single document. What you can do --
and if you're an entity subject to Sarbanes-Oxley, MUST do -- is require
that such calculations meet some standard of verifiability. The requirements
of Sarbanes-Oxley (and the equivalents outside the US) are pretty specific,
and methods like Macropod's fields simply don't meet them. It's more often a
problem with spreadsheets than with documents, but the principle is the
same.

 

[macropod]

Do some homework Jezebel.

The algorithms for converting to/from Julian day numbers are widely
available and verifiable. Any auditor (and I worked as one for the better
part of two decades), and anyone else whose interested (which you obviously
aren't) can verify whether the algorithms I've used are correct. Can you
verify that vba's behind-the-scenes algorithms for date calculations are
correct? How about Excel's? What about Access? Where are their algorithms
published? At least mine are there for all the world to see.

As for the merits of the Sarbanes-Oxley Act, the business and investment
community now has a widespread and growing view that the SOX does more
economic harm than good.

macropod
[Microsoft Word MVP]

 

[macropod]

Hi Tony,

To see how to do this and just about everything else you might want to do
with dates in Word, check out my Date Calc 'tutorial', at:
http://www.wopr.com/cgi-bin/w3t/showthreaded.pl?Number=249902


Cheers
PS: You can safely ignore Jezebel's rantings on this.

 

[Jezebel]

I've got no quarrell with the algorithms *behind* the calculations. The
issue is whether the calculations implement those algorithms correctly. They
might well do so; but the point is that in some circumstances, the *user*
(not you the code writer) needs to be able to prove it.

As for the merits of Sarbanes-Oxley: indeed it might be misguided and
unhelpful; but it's also (at least for the moment) a legal requirement,
which the poor punters on the IT shopfloor have to live with.

Do some homework Jezebel.

The algorithms for converting to/from Julian day numbers are widely
available and verifiable. Any auditor (and I worked as one for the better
part of two decades), and anyone else whose interested (which you
obviously
aren't) can verify whether the algorithms I've used are correct. Can you
verify that vba's behind-the-scenes algorithms for date calculations are
correct? How about Excel's? What about Access? Where are their algorithms
published? At least mine are there for all the world to see.

As for the merits of the Sarbanes-Oxley Act, the business and investment
community now has a widespread and growing view that the SOX does more
economic harm than good.

macropod
[Microsoft Word MVP]

The assertion that those field calculations "work" is questionable. They
certainly work *sometimes* -- but it's not easy to prove it -- which an
auditor is entitled to ask you to do.

Clearly some correspondence has legal significance -- particularly
letters
with statements like "do such-and-such within 28 days of the date of this
letter". As a matter of practical corporate goverance, obviously you
can't
check every single calculation in every single document. What you can do --
and if you're an entity subject to Sarbanes-Oxley, MUST do -- is require
that such calculations meet some standard of verifiability. The requirements
of Sarbanes-Oxley (and the equivalents outside the US) are pretty specific,
and methods like Macropod's fields simply don't meet them. It's more
often a
problem with spreadsheets than with documents, but the principle is the
same.

 

[macropod]

Have you bothered to examine and test the implementation? I doubt it. Yet
you're quite precious enough to decry its reliability on the one hand, and
to blithely accept whatever's been coded into vba, Excel, etc one the
other - with no access to the source code and, hence, little prospect of
being able to verify anything except that particular calculations work (or
don't) with the data used at the time of testing.

I've got no quarrell with the algorithms *behind* the calculations. The
issue is whether the calculations implement those algorithms correctly. They
might well do so; but the point is that in some circumstances, the *user*
(not you the code writer) needs to be able to prove it.

As for the merits of Sarbanes-Oxley: indeed it might be misguided and
unhelpful; but it's also (at least for the moment) a legal requirement,
which the poor punters on the IT shopfloor have to live with.

Do some homework Jezebel.

The algorithms for converting to/from Julian day numbers are widely
available and verifiable. Any auditor (and I worked as one for the better
part of two decades), and anyone else whose interested (which you
obviously
aren't) can verify whether the algorithms I've used are correct. Can you
verify that vba's behind-the-scenes algorithms for date calculations are
correct? How about Excel's? What about Access? Where are their algorithms
published? At least mine are there for all the world to see.

As for the merits of the Sarbanes-Oxley Act, the business and investment
community now has a widespread and growing view that the SOX does more
economic harm than good.

macropod
[Microsoft Word MVP]

The assertion that those field calculations "work" is questionable. They
certainly work *sometimes* -- but it's not easy to prove it -- which an
auditor is entitled to ask you to do.

Clearly some correspondence has legal significance -- particularly
letters
with statements like "do such-and-such within 28 days of the date of this
letter". As a matter of practical corporate goverance, obviously you
can't
check every single calculation in every single document. What you can do --
and if you're an entity subject to Sarbanes-Oxley, MUST do -- is require
that such calculations meet some standard of verifiability. The requirements
of Sarbanes-Oxley (and the equivalents outside the US) are pretty specific,
and methods like Macropod's fields simply don't meet them. It's more
often a
problem with spreadsheets than with documents, but the principle is the
same.






I have no argument that macro's are simpler (maybe not so simple in a mail
merge) - but you brought up 'legal significance' and there is none. The
field constructions may be complex, but they work (and in the final
analysis that is all that matters), and all the donkey work has already
been done.

--
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor - Word MVP

My web site www.gmayor.com

<>>< ><<> ><<> <>>< ><<> <>>< <>><<>


Jezebel wrote:
I think it would be irresponsible, in a formal application, to rely
on a field calculation of the Macropod sort. Those field sequences
(converting to Julian number and back) are technically -- ie, in the
audit sense -- 'complex calculations' of the sort that requires, in
any situation subject to audit, formally documented validation.
These is easily provided for macro code -- particularly for code as
trivial as adding 28 to a date; it is not easily provided for a
nested field calculation that runs to more than 300 characters and
five levels of nesting.


How do you think a date inserted by macro or even typed from the
keyboard would have greater legal significance than one inserted by
a field calculation?

--
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor - Word MVP

My web site www.gmayor.com

<>>< ><<> ><<> <>>< ><<> <>>< <>><<>


Jezebel wrote:
Unfortunately, Word doesn't provide a simple field-based way to do
date arithmetic. If you've got nothing better to do and yoru
document has no legal significance, you can experiment Macropod's
hilarious field calculations (do a Google); but if the requirement
is anything serious, you'll need to use a macro.








message Hey all,
I use Word97. I'm trying to create an auto update field that shows
the print date + 28 days in 'day, date month year' format in a
letter. The field code for the print date is: { PRINTDATE \@
"dddd, dd MMMM
yyyy" \* MERGEFORMAT }
I've experimented with a couple of things, but had no glory at all.
Cheers
Tony

 

[Jezebel]

Oh Macro, don't be such a f*cking twerp. What internal auditor is going to
accept that kind of answer?

Have you bothered to examine and test the implementation? I doubt it. Yet
you're quite precious enough to decry its reliability on the one hand, and
to blithely accept whatever's been coded into vba, Excel, etc one the
other - with no access to the source code and, hence, little prospect of
being able to verify anything except that particular calculations work (or
don't) with the data used at the time of testing.

I've got no quarrell with the algorithms *behind* the calculations. The
issue is whether the calculations implement those algorithms correctly. They
might well do so; but the point is that in some circumstances, the *user*
(not you the code writer) needs to be able to prove it.

As for the merits of Sarbanes-Oxley: indeed it might be misguided and
unhelpful; but it's also (at least for the moment) a legal requirement,
which the poor punters on the IT shopfloor have to live with.

Do some homework Jezebel.

The algorithms for converting to/from Julian day numbers are widely
available and verifiable. Any auditor (and I worked as one for the better
part of two decades), and anyone else whose interested (which you
obviously
aren't) can verify whether the algorithms I've used are correct. Can
you
verify that vba's behind-the-scenes algorithms for date calculations
are
correct? How about Excel's? What about Access? Where are their algorithms
published? At least mine are there for all the world to see.

As for the merits of the Sarbanes-Oxley Act, the business and
investment
community now has a widespread and growing view that the SOX does more
economic harm than good.

macropod
[Microsoft Word MVP]


The assertion that those field calculations "work" is questionable. They
certainly work *sometimes* -- but it's not easy to prove it -- which an
auditor is entitled to ask you to do.

Clearly some correspondence has legal significance -- particularly
letters
with statements like "do such-and-such within 28 days of the date of this
letter". As a matter of practical corporate goverance, obviously you
can't
check every single calculation in every single document. What you can
do --
and if you're an entity subject to Sarbanes-Oxley, MUST do -- is require
that such calculations meet some standard of verifiability. The
requirements
of Sarbanes-Oxley (and the equivalents outside the US) are pretty
specific,
and methods like Macropod's fields simply don't meet them. It's more
often
a
problem with spreadsheets than with documents, but the principle is
the
same.






I have no argument that macro's are simpler (maybe not so simple in a
mail
merge) - but you brought up 'legal significance' and there is none. The
field constructions may be complex, but they work (and in the final
analysis that is all that matters), and all the donkey work has already
been done.

--
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor - Word MVP

My web site www.gmayor.com

<>>< ><<> ><<> <>>< ><<> <>>< <>><<>


Jezebel wrote:
I think it would be irresponsible, in a formal application, to rely
on a field calculation of the Macropod sort. Those field sequences
(converting to Julian number and back) are technically -- ie, in
the
audit sense -- 'complex calculations' of the sort that requires, in
any situation subject to audit, formally documented validation.
These is easily provided for macro code -- particularly for code as
trivial as adding 28 to a date; it is not easily provided for a
nested field calculation that runs to more than 300 characters and
five levels of nesting.


How do you think a date inserted by macro or even typed from the
keyboard would have greater legal significance than one inserted
by
a field calculation?

--
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor - Word MVP

My web site www.gmayor.com

<>>< ><<> ><<> <>>< ><<> <>>< <>><<>


Jezebel wrote:
Unfortunately, Word doesn't provide a simple field-based way to
do
date arithmetic. If you've got nothing better to do and yoru
document has no legal significance, you can experiment Macropod's
hilarious field calculations (do a Google); but if the
requirement
is anything serious, you'll need to use a macro.








message
Hey all,
I use Word97. I'm trying to create an auto update field that shows
the print date + 28 days in 'day, date month year' format in a
letter. The field code for the print date is: { PRINTDATE \@
"dddd, dd MMMM
yyyy" \* MERGEFORMAT }
I've experimented with a couple of things, but had no glory at all.
Cheers
Tony

 

[macropod]

Is that the best you can do?

Oh Macro, don't be such a f*cking twerp. What internal auditor is going to
accept that kind of answer?

Have you bothered to examine and test the implementation? I doubt it. Yet
you're quite precious enough to decry its reliability on the one hand, and
to blithely accept whatever's been coded into vba, Excel, etc one the
other - with no access to the source code and, hence, little prospect of
being able to verify anything except that particular calculations work (or
don't) with the data used at the time of testing.

I've got no quarrell with the algorithms *behind* the calculations. The
issue is whether the calculations implement those algorithms correctly. They
might well do so; but the point is that in some circumstances, the *user*
(not you the code writer) needs to be able to prove it.

As for the merits of Sarbanes-Oxley: indeed it might be misguided and
unhelpful; but it's also (at least for the moment) a legal requirement,
which the poor punters on the IT shopfloor have to live with.





Do some homework Jezebel.

The algorithms for converting to/from Julian day numbers are widely
available and verifiable. Any auditor (and I worked as one for the better
part of two decades), and anyone else whose interested (which you
obviously
aren't) can verify whether the algorithms I've used are correct. Can
you
verify that vba's behind-the-scenes algorithms for date calculations
are
correct? How about Excel's? What about Access? Where are their algorithms
published? At least mine are there for all the world to see.

As for the merits of the Sarbanes-Oxley Act, the business and
investment
community now has a widespread and growing view that the SOX does more
economic harm than good.

macropod
[Microsoft Word MVP]


The assertion that those field calculations "work" is questionable. They
certainly work *sometimes* -- but it's not easy to prove it --

which
an

auditor is entitled to ask you to do.

Clearly some correspondence has legal significance -- particularly
letters
with statements like "do such-and-such within 28 days of the date of this
letter". As a matter of practical corporate goverance, obviously you
can't
check every single calculation in every single document. What you can
do --
and if you're an entity subject to Sarbanes-Oxley, MUST do -- is require
that such calculations meet some standard of verifiability. The
requirements
of Sarbanes-Oxley (and the equivalents outside the US) are pretty
specific,
and methods like Macropod's fields simply don't meet them. It's more
often
a
problem with spreadsheets than with documents, but the principle is
the
same.






I have no argument that macro's are simpler (maybe not so simple in a
mail
merge) - but you brought up 'legal significance' and there is none. The
field constructions may be complex, but they work (and in the final
analysis that is all that matters), and all the donkey work has already
been done.

--
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor - Word MVP

My web site www.gmayor.com

<>>< ><<> ><<> <>>< ><<> <>>< <>><<>


Jezebel wrote:
I think it would be irresponsible, in a formal application, to rely
on a field calculation of the Macropod sort. Those field sequences
(converting to Julian number and back) are technically -- ie, in
the
audit sense -- 'complex calculations' of the sort that requires, in
any situation subject to audit, formally documented validation.
These is easily provided for macro code -- particularly for code as
trivial as adding 28 to a date; it is not easily provided for a
nested field calculation that runs to more than 300 characters and
five levels of nesting.


How do you think a date inserted by macro or even typed from the
keyboard would have greater legal significance than one inserted
by
a field calculation?

--
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor - Word MVP

My web site www.gmayor.com

<>>< ><<> ><<> <>>< ><<> <>>< <>><<>


Jezebel wrote:
Unfortunately, Word doesn't provide a simple field-based way to
do
date arithmetic. If you've got nothing better to do and yoru
document has no legal significance, you can experiment Macropod's
hilarious field calculations (do a Google); but if the
requirement
is anything serious, you'll need to use a macro.








message
Hey all,
I use Word97. I'm trying to create an auto update field that shows
the print date + 28 days in 'day, date month year' format in a
letter. The field code for the print date is: { PRINTDATE \@
"dddd, dd MMMM
yyyy" \* MERGEFORMAT }
I've experimented with a couple of things, but had no glory at all.
Cheers
Tony