By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,098 Members | 1,893 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,098 IT Pros & Developers. It's quick & easy.

How do I get the full month name and not just the number?

P: n/a
jm
I am trying to use datepart to get the real name of the month like
"April" or "APR" not just "4." I could not find it in the
documentation. Sorry. Thank you.
Nov 12 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
jm wrote:
I am trying to use datepart to get the real name of the month like
"April" or "APR" not just "4." I could not find it in the
documentation. Sorry. Thank you.


Try these out for size. Go to the immediate window and enter
? Format(Date(),"mmm")
? Format(Date(),"mmmm")
? Format(Date(),"mmmmm")
? Format(Date(),"mmmmmm")

Nov 12 '05 #2

P: n/a
Salad wrote:
jm wrote:
I am trying to use datepart to get the real name of the month like
"April" or "APR" not just "4." I could not find it in the
documentation. Sorry. Thank you.

Try these out for size. Go to the immediate window and enter
? Format(Date(),"mmm")
? Format(Date(),"mmmm")
? Format(Date(),"mmmmm")
? Format(Date(),"mmmmmm")


I think you just want the 4 "m"s, I've not seen what the 5 or 6 do.

Speaking of which, I just ran an import and export from one of my
client's servers in Baku, in the export format the dates are in medium
date format. The month names came out in Turkish as the computer was set
to Turkish in Windows. Now the import, which imports dates in medium
date format in English, worked fine, given that... is it possible to
specify a date format that will always be in English regardless of the
computer's country settings?

I could run a function on the dates with ye olde faithful (Allen will
love this) mid("xxxJanFebMarAprMayJunJulAugSepOctNovDec",Mont h(date)*3+1,3)
but I was just wondering if Access could do it on it's todd.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer
Nov 12 '05 #3

P: n/a
"Trevor Best" <nospam@localhost> replied in message
news:40**********************@auth.uk.news.easynet .net...
I could run a function on the dates with ye olde faithful
(Allen will love this)
mid("xxxJanFebMarAprMayJunJulAugSepOctNovDec",Mont h(date)*3+1,3)


Aaaaaaaaaaagh No!!!!

:-)

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
Nov 12 '05 #4

P: n/a
Trevor,
Date datatypes are just doubles formatted to look like dates.

I would have thought it would be easier in the long run to use this fact
rather than worry about localisation issues.

(but then what would I know, not having any client servers in Baku <g>)

--
Terry Kreft
MVP Microsoft Access

"Trevor Best" <nospam@localhost> wrote in message
news:40**********************@auth.uk.news.easynet .net...
Salad wrote:
jm wrote:
I am trying to use datepart to get the real name of the month like
"April" or "APR" not just "4." I could not find it in the
documentation. Sorry. Thank you.

Try these out for size. Go to the immediate window and enter
? Format(Date(),"mmm")
? Format(Date(),"mmmm")
? Format(Date(),"mmmmm")
? Format(Date(),"mmmmmm")


I think you just want the 4 "m"s, I've not seen what the 5 or 6 do.

Speaking of which, I just ran an import and export from one of my
client's servers in Baku, in the export format the dates are in medium
date format. The month names came out in Turkish as the computer was set
to Turkish in Windows. Now the import, which imports dates in medium
date format in English, worked fine, given that... is it possible to
specify a date format that will always be in English regardless of the
computer's country settings?

I could run a function on the dates with ye olde faithful (Allen will
love this)

mid("xxxJanFebMarAprMayJunJulAugSepOctNovDec",Mont h(date)*3+1,3) but I was just wondering if Access could do it on it's todd.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

Nov 12 '05 #5

P: n/a
Trevor Best wrote:
Salad wrote:
jm wrote:
I am trying to use datepart to get the real name of the month like
"April" or "APR" not just "4." I could not find it in the
documentation. Sorry. Thank you.


Try these out for size. Go to the immediate window and enter
? Format(Date(),"mmm")
? Format(Date(),"mmmm")
? Format(Date(),"mmmmm")
? Format(Date(),"mmmmmm")

I think you just want the 4 "m"s, I've not seen what the 5 or 6 do.


I got carried away....just in case he wanted either APR/April as well as
the month number 4/04 at the same time <g>.

Regarding your international format question, I haven't dealt with
international date/currency problems. I can only pass back what MS has
said in help....

"Note Transferring data between computers with different regional
settings can result in incorrect currency data. For example, when using
the Currency format, a value of 5,47 kr on a computer set for Denmark
converts to $5.47 on a computer set for the United States. To prevent
such errors, define a custom format for the currency, such as #,## kr.
The custom format overrides the regional settings specified in the
Windows Control Panel. Similar problems won't occur when transferring
standard number, date, or time data between computers with different
regional settings."

I have not experimented in the import/export of international
values...but I don't understand how a custom format would be of much use
if the table stored US$, Mexican pesos, and Euros in a field. Do you
have separate fields based on the country of origin in displaying the
data? Too bad MS didn't provide some more verbose help and maybe a few
examples.

IOW, if you import the currency values from Denmark using the format
#,## kr, is the Denmark value stored internally as a value from Denmark
and if you import a currency with USD, it is in US$ format internally?
Do you set the field as type currency but leave the table's format row
blank in the property sheet so that it displays correctly?

I attemped the following with little success
? Format(5.47,"#,## kr")
returns
5 kr

? Format(5,47,"#,## kr")
returns a type mismatch.

Nov 12 '05 #6

P: n/a
"Terry Kreft" <te*********@mps.co.uk> wrote in
news:HI********************@karoo.co.uk:
Trevor,
Date datatypes are just doubles formatted to look like dates.


Terry

I think I have never disagreed with you before.

Surely "Date datatypes are just doubles" is too simple. If they are just
doubles do they have the same range? Do they have the same precision? Do
their operations behave in the same way (What about 0 - 0.5?)?

Would an 8 byte string be a double?

I think it is more appropriate to say that dates are stored as 8 bytes, as
doubles are.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)
Nov 12 '05 #7

P: n/a
Lyle,
I'm sure we have disagreed before, I'd be worried if we hadn't. That would
be boring and imply that one (or possibly both) of us is too smart for their
own good <g>.
To the objection
------------------
Hmmm, ok

From Access help

"... Double (double-precision floating-point) variables are stored as IEEE
64-bit (8-byte) floating-point numbers ranging in value
from -1.79769313486231E308 to -4.94065645841247E-324 for negative values and
from 4.94065645841247E-324 to 1.79769313486232E308 for positive values. ..."

"... Date variables are stored as IEEE 64-bit (8-byte) floating-point
numbers that represent dates ranging from 1 January 100 to 31 December 9999
and times from 0:00:00 to 23:59:59. ..."

So they are both IEEE 64-bit (8-byte) floating point numbers, the difference
is that a double has a wider range than a date therefore date is a subset of
double.

So I don't think I was too simplistic "dates are simply doubles" is correct
and was probably all that was required in context of the OP but then saying
"but not all doubles are dates", I agree, would have given the complete
picture.

How about: Date datatype and Double datatype are both 8 byte floating
numbers, it is possible to convert a date datatype variable to a double
datatype variable and within certain restrictions manipulate a date datatype
as if it were a double.
My conclusion would then be:-
You can Double Date but you can't necessarily Date Double.
--
Terry Kreft
MVP Microsoft Access
"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...
"Terry Kreft" <te*********@mps.co.uk> wrote in
news:HI********************@karoo.co.uk:
Trevor,
Date datatypes are just doubles formatted to look like dates.


Terry

I think I have never disagreed with you before.

Surely "Date datatypes are just doubles" is too simple. If they are just
doubles do they have the same range? Do they have the same precision? Do
their operations behave in the same way (What about 0 - 0.5?)?

Would an 8 byte string be a double?

I think it is more appropriate to say that dates are stored as 8 bytes, as
doubles are.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

Nov 12 '05 #8

P: n/a
"Terry Kreft" <te*********@mps.co.uk> wrote in
news:Sr********************@karoo.co.uk:
Lyle,
I'm sure we have disagreed before, I'd be worried if we hadn't. That
would be boring and imply that one (or possibly both) of us is too smart
for their own good <g>.
To the objection
------------------
Hmmm, ok

From Access help

"... Double (double-precision floating-point) variables are stored as
IEEE 64-bit (8-byte) floating-point numbers ranging in value
from -1.79769313486231E308 to -4.94065645841247E-324 for negative values
and from 4.94065645841247E-324 to 1.79769313486232E308 for positive
values. ..."

"... Date variables are stored as IEEE 64-bit (8-byte) floating-point
numbers that represent dates ranging from 1 January 100 to 31 December
9999 and times from 0:00:00 to 23:59:59. ..."

So they are both IEEE 64-bit (8-byte) floating point numbers, the
difference is that a double has a wider range than a date therefore date
is a subset of double.

So I don't think I was too simplistic "dates are simply doubles" is
correct and was probably all that was required in context of the OP but
then saying "but not all doubles are dates", I agree, would have given
the complete picture.

How about: Date datatype and Double datatype are both 8 byte floating
numbers, it is possible to convert a date datatype variable to a double
datatype variable and within certain restrictions manipulate a date
datatype as if it were a double.
My conclusion would then be:-
You can Double Date but you can't necessarily Date Double.


Great. I agree and ...
I'll bring a redhead!

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)
Nov 12 '05 #9

P: n/a
Mines brunette, you get the first round ... <g>

--
Terry Kreft
MVP Microsoft Access
"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...
"Terry Kreft" <te*********@mps.co.uk> wrote in
news:Sr********************@karoo.co.uk:
Lyle,
I'm sure we have disagreed before, I'd be worried if we hadn't. That
would be boring and imply that one (or possibly both) of us is too smart
for their own good <g>.
To the objection
------------------
Hmmm, ok

From Access help

"... Double (double-precision floating-point) variables are stored as
IEEE 64-bit (8-byte) floating-point numbers ranging in value
from -1.79769313486231E308 to -4.94065645841247E-324 for negative values
and from 4.94065645841247E-324 to 1.79769313486232E308 for positive
values. ..."

"... Date variables are stored as IEEE 64-bit (8-byte) floating-point
numbers that represent dates ranging from 1 January 100 to 31 December
9999 and times from 0:00:00 to 23:59:59. ..."

So they are both IEEE 64-bit (8-byte) floating point numbers, the
difference is that a double has a wider range than a date therefore date
is a subset of double.

So I don't think I was too simplistic "dates are simply doubles" is
correct and was probably all that was required in context of the OP but
then saying "but not all doubles are dates", I agree, would have given
the complete picture.

How about: Date datatype and Double datatype are both 8 byte floating
numbers, it is possible to convert a date datatype variable to a double
datatype variable and within certain restrictions manipulate a date
datatype as if it were a double.
My conclusion would then be:-
You can Double Date but you can't necessarily Date Double.


Great. I agree and ...
I'll bring a redhead!

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

Nov 12 '05 #10

P: n/a
Terry Kreft wrote:
Trevor,
Date datatypes are just doubles formatted to look like dates.

I would have thought it would be easier in the long run to use this fact
rather than worry about localisation issues.

(but then what would I know, not having any client servers in Baku <g>)


My Client has to export their data to their client, who expects the
dates to be dd-mmm-yy format. Even if we could agree to exchange numbers
instead of dates, there's no guaruntee that the foriegn system will use
the same base date for the value 0.

IMHO the safest way is to use international format yyyy-mm-dd. I thought
medium dates would eliminate the ambiguity of British vs American dates
until we hit the language problem :-)

--
Error reading sig - A)bort R)etry I)nfluence with large hammer
Nov 12 '05 #11

P: n/a
Salad wrote:
Trevor Best wrote:
Salad wrote:
jm wrote:

I am trying to use datepart to get the real name of the month like
"April" or "APR" not just "4." I could not find it in the
documentation. Sorry. Thank you.


Try these out for size. Go to the immediate window and enter
? Format(Date(),"mmm")
? Format(Date(),"mmmm")
? Format(Date(),"mmmmm")
? Format(Date(),"mmmmmm")


I think you just want the 4 "m"s, I've not seen what the 5 or 6 do.

I got carried away....just in case he wanted either APR/April as well as
the month number 4/04 at the same time <g>.

Regarding your international format question, I haven't dealt with
international date/currency problems. I can only pass back what MS has
said in help....

"Note Transferring data between computers with different regional
settings can result in incorrect currency data. For example, when using
the Currency format, a value of 5,47 kr on a computer set for Denmark
converts to $5.47 on a computer set for the United States. To prevent
such errors, define a custom format for the currency, such as #,## kr.
The custom format overrides the regional settings specified in the
Windows Control Panel. Similar problems won't occur when transferring
standard number, date, or time data between computers with different
regional settings."

I have not experimented in the import/export of international
values...but I don't understand how a custom format would be of much use
if the table stored US$, Mexican pesos, and Euros in a field. Do you
have separate fields based on the country of origin in displaying the
data? Too bad MS didn't provide some more verbose help and maybe a few
examples.

IOW, if you import the currency values from Denmark using the format
#,## kr, is the Denmark value stored internally as a value from Denmark
and if you import a currency with USD, it is in US$ format internally?
Do you set the field as type currency but leave the table's format row
blank in the property sheet so that it displays correctly?

I attemped the following with little success
? Format(5.47,"#,## kr")
returns
5 kr

? Format(5,47,"#,## kr")
returns a type mismatch.

How I handle currency is to store the value in whatever currency the
order is in along with two exchange rates, one for project, one for
office. E.g. You may have a British company operating a project in the
US buying stuff in Yen so the order would be in Yen, the project
currency is USD and the office currency is UKP. Reports to the client
will tally things up in the project currency and reports to the head
office will tally things up in the office currency.

As regards format, this is one of the biggest PITAs in Access, if you
use the currency data type and don't specify a format, it always shows
in the currency format, e.g. $0.00. This is fine if you're a small
business and never deal internationally and handle other currencies, I
don't know many companies like that. Some of my clients even place
orders in multi currency so you may have one order with a load of stuff
in USD and a couple of items in local currency so I have to explicitly
format all currency data as Standard.

Now the real pain, no matter what format you specify in a table or
query, exporting the data will always put the frikkin currency symbol
back on so for exports you always have to format(field,"0.00") or
cdbl(field)

--
Error reading sig - A)bort R)etry I)nfluence with large hammer
Nov 12 '05 #12

P: n/a
Trevor Best wrote:
How I handle currency is to store the value in whatever currency the
order is in along with two exchange rates, one for project, one for
office. E.g. You may have a British company operating a project in the
US buying stuff in Yen so the order would be in Yen, the project
currency is USD and the office currency is UKP. Reports to the client
will tally things up in the project currency and reports to the head
office will tally things up in the office currency.

As regards format, this is one of the biggest PITAs in Access, if you
use the currency data type and don't specify a format, it always shows
in the currency format, e.g. $0.00. This is fine if you're a small
business and never deal internationally and handle other currencies, I
don't know many companies like that. Some of my clients even place
orders in multi currency so you may have one order with a load of stuff
in USD and a couple of items in local currency so I have to explicitly
format all currency data as Standard.
That is why I was wondering if you maybe had a lookup table to link
formats based on currency/country to the record or had an extra field to
store the format for each record.
Now the real pain, no matter what format you specify in a table or
query, exporting the data will always put the frikkin currency symbol
back on so for exports you always have to format(field,"0.00") or
cdbl(field)


When you posed the question I first thought this should be situation
that MS could fix. I sometimes wonder how many thousands of man hours
have been spent trying to figure out a FileOpen routine or answering the
question on where to find FileOpen then the time to go to the code and
paste it into modules. I could see roll-your-own in VB, but not in
something like Access.

So you'd think MS could have function like
FormatToCountry(DateField,"Thailand") and you don't really care how its
stored, exported, or imported. Or in your case
FormatToCountry(CurrencyVal,"Chinese",blnNoDollar" ). If they did it,
and was part of the system, and optimized, people don't get bogged down
in mundane chores or need to ask questions on newsgroups.

Maybe Michka has some pull....get it in the next release.

Nov 12 '05 #13

P: n/a
In cases like these where there are lets say points of contention about date
formats I just fall back on the ISO standards (ISO 8601 if I recall
correctly), code my work to agree with that and insist that the other party
does the same, this way at least you've got an international standard to
work to.

Of course once the data is transferred you can display it however your
client wants it to look like.
--
Terry Kreft
MVP Microsoft Access
"Trevor Best" <nospam@localhost> wrote in message
news:40***********************@auth.uk.news.easyne t.net...
Terry Kreft wrote:
Trevor,
Date datatypes are just doubles formatted to look like dates.

I would have thought it would be easier in the long run to use this fact
rather than worry about localisation issues.

(but then what would I know, not having any client servers in Baku <g>)


My Client has to export their data to their client, who expects the
dates to be dd-mmm-yy format. Even if we could agree to exchange numbers
instead of dates, there's no guaruntee that the foriegn system will use
the same base date for the value 0.

IMHO the safest way is to use international format yyyy-mm-dd. I thought
medium dates would eliminate the ambiguity of British vs American dates
until we hit the language problem :-)

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

Nov 12 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.