Creating a date field in 3 day in advance of current date
Wis...@officeformac.com
Version: 2008
Operating System: Mac OS X 10.5 (Leopard)
Processor: Intel
I want to insert a date field which adds 3 days of the current date automatically in Word 2008 Mac.
So if I insert a field with today date 07/07/2009 I want it to say 10/07/2009 and so on.
I trailed through the searches and found numerous ways but they do not seem to work: <http://help.lockergnome.com/office/Adding-days-Merge-Field--ftopict949591.html>
I also followed points in this file DateCalc.zip found here: <http://www.gmayor.com/downloads.htm#Third_party>
If you could guide me through this that would e great.
macropod
Hi Wishful,
To see how to do this and just about everything else you might want to do with dates in Word, check out my Word Date Calculation
Tutorial, at:
http://www.wopr.com/index.php?showtopic=249902
or
http://www.gmayor.com/downloads.htm#Third_party
In particular, look at the item titled 'Calculate a day, date, month and year, using n days delay'. Do read the document's
introductory material. If you need to allow for weekends, check out the 'Handling Weekends and Holidays in Calculated Dates' example
also.
For your purposes, simply change the 'Delay' value in the field to 3.
--
Cheers
macropod
[Microsoft MVP - Word]
<Wis...@officeformac.com> wrote in message news:59b77...@webcrossing.caR9absDaxw...
John McGhie
The basics of what you need are to understand that to a computer, a "Date"
is simply part of a "Time" and that both are simply a large integer (a
number).
In Microsoft applications, the date is actually in seconds since Jan 1,
1900. You simply need to add three days' worth of seconds to it (259200
seconds).
Word makes this easier by offering variables that split the date up for you,
so you can chop it up into its component parts, or add a single multiple).
Graham and Macropod's pages will show you how...
Working with dates is very easy, provided that you leave them as numbers.
Don't turn them into text at any stage: simply display them as text when you
want to. Once you have turned a date into text, getting it back into a
number upon which you can operate is extremely complex and a little
unreliable.
Which is why so many disasters are created with American dates :-) You
cannot reliably convert an American date unless you know for certain that it
is an American date! And in a piece of text, there's nothing reliable to
tell you this.
Cheers
On 7/07/09 9:34 PM, in article 59b77...@webcrossing.caR9absDaxw,
"Wis...@officeformac.com" <Wis...@officeformac.com> wrote:
--
Don't wait for your answer, click here: http://www.word.mvps.org/
Please reply in the group. Please do NOT email me unless I ask you to.
John McGhie, Microsoft MVP, Word and Word:Mac
Sydney, Australia. mailto:jo...@mcghie.name
macropod
> You cannot reliably convert an American date unless you know for certain
> that it is an American date! And in a piece of text, there's nothing reliable
> to tell you this.
I disagree - "July 7, 2009" is an 'obviously' US date, and my field coding will correctly process such a date, regardless of the
OS's regional settings. A string such as 07/08/09, however, is impossible to conclusively interpret as to day, month or century,
which is why I said: "Do read the document's introductory material."
--
Cheers
macropod
[Microsoft MVP - Word]
"John McGhie" <jo...@mcghie.name> wrote in message news:C67AAA7D.2000B%jo...@mcghie.name...
Wis...@officeformac.com
Sorry I failed to mention that I prefer the dates to be UK: DD/MM/YYYY
Those links are the ones I tried and tested, and I'm guessing I'm missing a trick somewhere.
But I will attempt it again and will let you know how I get on.
Thank you for your help, any further guidance would be great!
Clive Huggan
Don't worry, Wishful: you are being looked after by two Aussies, and a
highly civilized, internationalized pair of chaps they are too...
(Just realized this will make no sense to Texans and others from bovine
areas of the US.)
Cheers,
Clive Huggan
Canberra, Australia
===================
On 8/7/09 11:34 PM, in article 59b77...@webcrossing.caR9absDaxw,
"Wis...@officeformac.com" <Wis...@officeformac.com> wrote:
> Sorry I failed to mention that I prefer the dates to be UK: DD/MM/YYYY
>
<snip>
John McGhie
Hi ...
What are you disagreeing with?? :-)
Cheers
On 8/07/09 10:16 PM, in article eeyT1Y8$JHA....@TK2MSFTNGP04.phx.gbl,
"macropod" <macr...@invalid.invalid> wrote:
> Hi John,
>
>> You cannot reliably convert an American date unless you know for certain
>> that it is an American date! And in a piece of text, there's nothing
>> reliable
>> to tell you this.
> I disagree - "July 7, 2009" is an 'obviously' US date, and my field coding
> will correctly process such a date, regardless of the
> OS's regional settings. A string such as 07/08/09, however, is impossible to
> conclusively interpret as to day, month or century,
> which is why I said: "Do read the document's introductory material."
This email is my business email � Please do not email me about forum matters
unless you intend to pay!
--
John McGhie, Microsoft MVP (Word, Mac Word), Consultant Technical Writer,
McGhie Information Engineering Pty Ltd
Sydney, Australia. | Ph: +61 (0)4 1209 1410
+61 4 1209 1410, mailto:jo...@mcghie.name
macropod
Hi john,
I disagree with the bit about "in a piece of text, there's nothing reliable to tell you this".
--
Cheers
macropod
[Microsoft MVP - Word]
"John McGhie" <jo...@mcghie.name> wrote in message news:C67D5006.CCF%jo...@mcghie.name...
John McGhie
I thought so: Obviously if the name of the month is spelled in full, you
can make a good guess. You are more sure if you also find four digits one
word to the right of the name of the month, and they happen to be within ten
years either side of this year.
But in programmatic terms, you are not "certain" :-)
Cheers
On 10/07/09 10:41 PM, in article uUUoWwVA...@TK2MSFTNGP03.phx.gbl,
"macropod" <macr...@invalid.invalid> wrote:
> Hi john,
>
> I disagree with the bit about "in a piece of text, there's nothing reliable to
> tell you this".
This email is my business email � Please do not email me about forum matters
Peter Jamieson
One of the problems with Word and dates is that whatever the format used
by the data source to store dates, by the time Word gets its data from
the data source, it is typically actually in text format. So you don't
actually have the opportunity to deal directly with a numeric date value.
That means that whatever method is used to get the data from the data
source has to recognise date data reliably, and you also have to be sure
that if you use, for example
{ MERGEFIELD \@D } to extract the day of the month, that will work
whether Word displays the date as
D/M/Y
or
M/D/Y
This, AFAICS, is the reason for a rather nasty kludge in recent versions
of Word - which is that Word actually changes its interpretation of date
strings such as 2/9/2009 depending on whether or not it is connected to
a data source using OLE DB.
Because I've always had a somewhat arbitrary experience trying to look
at this stuff, I would be interested to see if those set up with Windows
systems where the date format is DD/MM/YYYY have the same experience as
I do.
To do that, what you need is
a. (say) Word 2007 or Word 2003
b. A Word file, not connected to any data source, with the following
fields:
{ SET X "2/9/2009" }
{ X }
{ X \@"DD MMM YYYY" }
AFAICS when you update and toggle those fields, you should see
2/9/2009
2/9/2009
02 Sep 2009
Then connect to (say) an Excel data source. If you are offered the
choice, choose the OLE DB Databases option. Here, I see the 02 Sep 2009
change to 09 Feb 2009
So if your data source was an excel file containing
k d
1 2/9/2009
(i.e. that's a proper Excel format date with D/M/YYYY format, i.e. 2nd
Sep 2009) and you inserted
{ MERGEFIELD d }
{ MERGEFIELD d \@"DD MMM YYYY" }
and toggle the field codes, you should see
9/2/2009
02 Sep 2009
In other words, whatever your regional settings, with an OLE DB
connection, a date mergefield with no date format is displayed in a "US
format", which is a source of understandable irritation for many. I feel
sure that this is not the whole story, though.
X/Y/ZZZZ "literals" that could be either D/M/YYYY or M/D/YYYY are
assumed to be M/D/YYYY (or D-M-YYYY, M-D-YYYY, I don't think it makes
any difference) assumed to be M/D/YYYY.
Connecting via e.g. ODBC does not have this effect. So anyone designing
a merge application really has to be careful about introducing date
literals (however they are constructed) especially if they do not know
what type of connection wil be used. Personally I would always favour
constructing date/times specified in a YYYY-MM-DD style format on the
grounds that
a. they do not suffer from this particular problem (although you have
to be careful about how you compare them in IF fields)
b. they will sort well even with sort operations that don't know they
are dates.
However, at least Excel dates that are not stored as text are reasonably
unambiguous (forgetting about the 1904 date system). If you are getting
dates from a text file (in Windows), things are more complicated because
the Excel numeric format is not supported AFAIK (although you could
use a numeric format and use macropod's field stuff to coerce it into a
display format), so you would typically have to use a text format of
some kind. If Word opens the file using its internal text converter,
which it will if it can't do it using OLE DB (e.g. over 255 fields)
you'll see the dates as they are in the file. But the OLE DB
provider/ODBC provider interprets them at least partly according to your
regional settings (whereas of course in many cases the text file may
have been created on a system with different assumptions), and/or any
date format you may have specified in a schema.ini.
Peter Jamieson
Peter Jamieson
> Then connect to (say) an Excel data source. If you are offered the
> choice, choose the OLE DB Databases option. Here, I see the 02 Sep 2009
> change to 09 Feb 2009
Peter Jamieson
Peter Jamieson
thread has any interest in pinning down any of the stuff I mentioned,
you are welcome to despam my email and contact me.
Peter Jamieson