🚀 go-pugleaf

> Now we are trying to do the same thing in Java. However, try as I might, I
> cannot find a Java class that will return the contents of an environment
> variable, or a class that will return a formatted date/time string given a
> simple format definition string.
>
> Can anyone suggest a way in which we can elegantly return a formatted
> date/time string in Java using our existing environment variable?

For some information, read the JavaDocs for;
java.lang.System.getenv(String)

Note that you could, with a script, turn an environment variable into a
property (eg. pass with -D) fairly easily.


Also take a look at the class;
java.text.SimpleDateFormat
I wonder... it probably wouldn't be too hard to transform the format
pattern... or you may be lucky; somebody may have already implemented a
java.text.DateFormat that is compatible with your format pattern.

-Benjamin Johnston
s355171@student.uq.edu.au

"Doug Rickard" <rickard@primus.com.au> wrote in message
news:39e107db@news.iprimus.com.au...
> variable, or a class that will return a formatted date/time string given a
> simple format definition string.

If all you want to do is convert dates which you *already know* are going to
be in 'DD-MMM-YYYY' format (eg, in a flat text file), then what you need is
a java.text.SimpleDateFormat().

  DateFormat df = new SimpleDateFormat("dd-MMM-yyyy");
  Date end_date = df.parse("12-JAN-1987");

If you have something more complicated in mind:

Java has three related classes that do date/time stuff.

java.util.Date. This class encapsulates the idea of a moment in time. A date
is like a number. The only operations you can do on a date is compare one to
another for greaterthan/lessthan/equalto. It is an "opaque" class - it's
actual contents are NOYB, however, most jvm implementations will represent
dates as a number of miliseconds since 1-Jan-1970 GMT.

java.util.Calendar. This class encapsulates the idea of dividing time up
into named intervals (days, months, eras, lunar cycles etc). A calendar is a
thing that says "that point of time is during a Tuesday in March". One
could, in theory, make up a calendar for mars or for the sidreal year
(rather than the solar) and plug it into the existing date/time
infrastructure. Try that with windows!

java.text.DateFormat. This class encapulates the idea of using a text string
to specify a Date.

Oh - and other classes of interest are java.util.Locale, which represents a
geographical, political, or cultural region; and java.util.TimeZone, which
is a time zone (duh).

The locale in which a jvm is running is a system property. Java does not use
environment variables - it uses properties. These properties should have
been set up when the jvm was installed. You get the default Locale with
    Locale.getDefault();

and the default TimeZone with
    TimeZone.getDefault();

which are a static methods. There may be more than one Locale in a timezone
(eg: nth and sth america), and more than one Timezone in a Locale (eg, the
USA). For what you want you probably don't need these classes directly, but
if you need the user to indicate where they are, you can construct a
picklists from Locale.getAvailableLocales(), and TimeZone.getAvailableIDs().
This also handy for internationalising your app with resource bundles (a
Locale also includes the concept of a language, CA_EN vs. CA_FR).

The next thing you need is a Calendar. If you use
  Calendar.getInstance(),

you'll get a calendar which is of the default type for your system locale,
initialised to the current time. In most places, the calendar you get back
will be an instance of GregorianCalendar. I suppose there is an
implementation of the Chinese calendar out there somewhere if you need it.
If you are giving your users a picklist of locales, you can use
   Calendar.getInstance(Locale)
   Calendar.getInstance(TimeZone)
   Calendar.getInstance(TimeZone, Locale)

to get a calendar for the locale they chose. Of course, you can specifically
use a GregorianCalendar
   Calendar cal = new GregorianCalendar();
   Calendar cal = new GregorianCalendar(user_locale);

if you don't want to deal with the Year of the Rat, roman Ides and Calends,
or Jovian sidreal years (the day on Jupiter is 10 earth-hours long).
Calendars allow you to do things like adding one day to a date, or finding
the first weekday of next month. Some things are specific to certain types
of calendar - eg, finding the next year of the Rat. If you are dealing with
concepts like "month" and "day of the week", then you may need to admit that
you are assuming a Gregorian calendar, and explicitly construct one. It's
nothing to be ashamed of, everyone does it.

So. You have a localised calendar. Each calendar may have several ways of
specifying dates as text. To convert text strings to non-text values, you
use a java.Text.Format. There is a subclass of this, java.Text.DateFormat,
for handling dates.

To get a default date formatter for the current locale, use
    java.text.DateFormat.getInstance();
    java.text.DateFormat.getDateInstance();
    java.text.DateFormat.getTimeInstance();
    java.text.DateFormat.getDateTimeInstance();
as applicable
*** MOST OF THE TIME, THIS IS ALL YOU NEED TO DO ***

just call
  formatter.parse(userInputString)
to convert a string to a date, or
   formatter.format(employeeTerminationDate)
to convert a date to a string

'Xcuse the shouting, but that was for people just flicking through this
post. getDateInstance should correctly return dd/mm/yyyy, mm/dd/yyyy,
dd.mm.yyyy, yyyy.mm.dd etc for wherever the user happens to be when it is
run.

You can ask for a long, medium or short date/time by calling
    DateFormat.getInstance(DateFormat.LONG)
    DateFormat.getInstance(DateFormat.MEDIUM)
    DateFormat.getInstance(DateFormat.SHORT)
    DateFormat.getInstance(DateFormat.DEFAULT)
    DateFormat.getInstance(DateFormat.FULL)

The meanings of which depend on the calendar and the locale.

And, of course, you can
    DateFormat.getDateInstance(DateFormat.FULL, Locale.FRENCH)

For a long format french date format, and I presume
    DateFormat df = new DateFormat();
    df.setCalendar(new WiccanLunarCalendar());

to plan your next sabbat.

And this is as much as I know about the topic. It took me a while to figure
it out, but it's very very neat, really. Cheers!

--------------------------------------------------------------
Repent! Quit your job! Slack off!
http://www.users.bigpond.com/pmurray
ICQ: 26066755

Paul Murray <pmurray@nospam.bigpond.com> wrote in message
news:STgE5.66838$c5.184944@newsfeeds.bigpond.com...
> "Doug Rickard" <rickard@primus.com.au> wrote in message
> news:39e107db@news.iprimus.com.au...
> > variable, or a class that will return a formatted date/time string given
a
> > simple format definition string.

Paul,

Thank you very much for your in depth response. It makes me wonder however
if Java is appropriate as our upgrade language. If what we consider as a
simple but integral feature of our applications becomes such a complex issue
under Java, we may well be better off staying away from Java completely.

Thank you for your time.

Doug.

"Doug Rickard" <rickard@primus.com.au> wrote in message
news:39e1b447@news.iprimus.com.au...

> Thank you very much for your in depth response. It makes me wonder however
> if Java is appropriate as our upgrade language. If what we consider as a
> simple but integral feature of our applications becomes such a complex
issue
> under Java, we may well be better off staying away from Java completely.

Well, I think Java is wonderful, so I'll take moment to advocate it. I
regret frigtening you off, if that's what Iv'e done.

The complexity is there only because these internationalisation issues were
considered from day one. Those things that become problems later on are
already taken care of, at the price of a small learning-curve increase. If
you need full-on tricky things to do with calendars, then it's not a
separate library you have to load: it's integrated into the APIs. If all you
want to do is convert strings to and from, using the local calendar, then
you call DateFormat.getInstance() to get a class to do it. It has a parse()
and a format(). t doesn't get much simpler than that. Particularly
considering how difficult it can be to make a "simpler" system do exactly
what you need, if the fit is not perfect.

Another issue is text input and output streams - "Writers" as opposed to
"Streams". The complexity is there because java, quietly and without fuss,
will handle greek, crillic, chinese, kanjii etc without these windows "code
page" things. Most of the time it just doesn't matter. You can string
compare two strings, dump them to a file, save them in a database, send them
across the world via a CORBA call and never worry that one of them might be
in thai or telugu.

As for environment variables - there's ongoing discussion as we speak. Yes,
java is still a work in progress. Java has a general config mechanism -
properties in property files. Environment variables are not always relevant
(eg, in EJBs). In windows, they are an anachronism - aren't we supposed to
be using the registry for this kind of thing these days?

That said: if you are writing a windows app to run on windows, Visual Basic
or Visual C++ are still excellent choices. There's an existing skill base,
the tools have fewer bugs, and it's faster. If there are reasons you were
looking at Java, specifically, they are probably still good. However,
learning the APIs and the Java-ish way to accomplish things is a significant
task, and not to be underestimated. You can fool around for hours trying to
break your string into chunks using .substring() and .charAt(), or you can
use a StringTokeniser, which is what it's for. You have to know it's there
first, though.

Or you can hire me <g>.

--------------------------------------------------------------
Repent! Quit your job! Slack off!
http://www.users.bigpond.com/pmurray
ICQ: 26066755

Paul Murray <pmurray@nospam.bigpond.com> wrote in message
news:YABE5.67451$c5.186717@newsfeeds.bigpond.com...
> "Doug Rickard" <rickard@primus.com.au> wrote in message
> news:39e1b447@news.iprimus.com.au...

> Well, I think Java is wonderful, so I'll take moment to advocate it. I
> regret frigtening you off, if that's what Iv'e done.

Always ready to listen to an informed discussion from someone who knows what
they are talking about..

> As for environment variables - there's ongoing discussion as we speak.
Yes,
> java is still a work in progress. Java has a general config mechanism -
> properties in property files. Environment variables are not always
relevant
> (eg, in EJBs). In windows, they are an anachronism - aren't we supposed to
> be using the registry for this kind of thing these days?

I have a series of code libraries built up over a period of about 30+ years.
I can generally put togethet a full client /server based data base system to
a customers specification in under an hour. My standard client code skeleton
runs on DOS, Win95/98/2000/NT, Linux/Unix, VMS, etc without alteration. One
of the things I have aimed for is user configurability. Each user can
configure just about every single characteristic of the system as he see it
by means of environment variables/logical names. The user can change
date/time formats, screen layout, character size, font, colours, etc etc to
their own particular likes and dislikes. Things like the Windows registry
are a system wide feature, not a user accessable feature. I sometimes have
up to 30 to 40 variables to configure the system at actual run time. The
users absolutely love these features. I have often won contracts based on
this configurability feature alone. However, I take your point on
configuration files. It may be time to change my approach and use
user-editable configuration files. There is no reason the same type of
information could not be obtained from a configuration file instead of
environment variables. If fact my current approach is to define the
environment variables in the users start up file. It's just one file or
another. Must look into that approach more deeply.

However I feel the need to move up to a more modern language environment.
During the first half of this year while in hospital for 3 months I made a
particular point of learning C++ so as to be able to evaluate its
suitability as a new standard. I was able to convert all our existing
special features over to C++ without any problems, and it gave me a taste
for object orientated languages.

Now I wish to try a similar evaluation of Java. I am taking some of the
configurability features and seeing if I can convert each one of them to
Java. So far this has proven to be fairly difficult. A couple of other
respondents to this newsgroup have come up with some suggestions that bear
looking into, and I hope to do this as soon as possible. However it looks
like moving to Java means discarding libraries built up over 30 years and
starting afresh. Code reusability has always been my motto, and all my
existing libraries have been used over and over many times, even though they
have been written in a wide range of languages. The Java concept seems to be
that you can only reuse Java code, and only for Java applications.

I must admit that we got a simple client/server working under Java last
night, but the problems of how to personalise it still seem daunting at this
stage.

> That said: if you are writing a windows app to run on windows, Visual
Basic
> or Visual C++ are still excellent choices. There's an existing skill base,
> the tools have fewer bugs, and it's faster.

Yes, we have used VB, and for process control systems, and in fact one of my
son's VB programs was reviewed in the January-2000 issue of the magazine
Silicon Chips.

>If there are reasons you were
> looking at Java, specifically, they are probably still good. However,
> learning the APIs and the Java-ish way to accomplish things is a
significant
> task, and not to be underestimated.

Yes, trying to evaluate the balance of the steep learning curve vs. any
productivity improvements is a difficult one.

> Or you can hire me <g>.

Maybe once upon a time. I am actually retired these days because of medical
reasons. I was a senior consultant for one of the larger computer companies
for many years. These days I still act as an adviser to many companies just
for the fun of it, otherwise I would go crazy. I love people coming to me
with a problem that they think is insoluble, and then showing them a working
prototype in under an hour.

Thanks for the discussion. Much appreciated.

Regards,

Doug.

> simple but integral feature of our applications becomes such a complex
issue
> under Java, we may well be better off staying away from Java completely.

Yeah, I think you should stay with what you are used to, away from java.
Doug,
 you gave an excelent answear but spoiled it for this wanker to find out by
him self...

Just to add to the 'confusion', the Date object is slowly being 'deprecated'
having to work closely with the system miliseconds.
The same being used by high level C libs.
I remember that there are few jars out there which take into acount
over -30000 to + 30000 years. 0 being Christs date of birth. The system mils
are valid from year 1700 till ?
Complex?, no, pure fun...at least you don't have to worry that you get
suprised by a bootup screen while testing.


Doug Rickard <rickard@primus.com.au> wrote in message
news:39e1b447@news.iprimus.com.au...
>
> Paul Murray <pmurray@nospam.bigpond.com> wrote in message
> news:STgE5.66838$c5.184944@newsfeeds.bigpond.com...
> > "Doug Rickard" <rickard@primus.com.au> wrote in message
> > news:39e107db@news.iprimus.com.au...
> > > variable, or a class that will return a formatted date/time string
given
> a
> > > simple format definition string.
>
> Paul,
>
> Thank you very much for your in depth response. It makes me wonder however
> if Java is appropriate as our upgrade language. If what we consider as a
> simple but integral feature of our applications becomes such a complex
issue
> under Java, we may well be better off staying away from Java completely.
>
> Thank you for your time.
>
> Doug.
>
>

"Doug Rickard" <rickard@primus.com.au> wrote in message
news:39e3dfba@news.iprimus.com.au...
>
> I have a series of code libraries built up over a period of about 30+
years.
> I can generally put togethet a full client /server based data base system
to
> a customers specification in under an hour. My standard client code
skeleton
> runs on DOS, Win95/98/2000/NT, Linux/Unix, VMS, etc without alteration.

Yeah. If you have that much of an investment in legacy code, then changing
to anything else is a major step.

> However it looks
> like moving to Java means discarding libraries built up over 30 years and
> starting afresh.

I'd say so. I'm a C programmer myself, and good C code often involves doing
magic stuff with pointer arithmentic. It's the major technique that you use
and java simply doesn't have it.

> Code reusability has always been my motto, and all my
> existing libraries have been used over and over many times, even though
they
> have been written in a wide range of languages. The Java concept seems to
be
> that you can only reuse Java code, and only for Java applications.

Yep. Pretty much. You can integrate java and other languages with JNI: the
"Java Native Interface". This allows you to write high-level stuff in java
but the workhorse libraries in something quicker. Perhaps that would ne
something fruitful to look at.


> >If there are reasons you were
> > looking at Java, specifically, they are probably still good. However,
> > learning the APIs and the Java-ish way to accomplish things is a
> significant
> > task, and not to be underestimated.
>
> Yes, trying to evaluate the balance of the steep learning curve vs. any
> productivity improvements is a difficult one.

Yep. I decided a while back that I wanted to move out of MS-Access (which
was where I was headed) and switch to Java. It was a risk, and a career
choice.

> > Or you can hire me <g>.
>
> Maybe once upon a time.

It was worth a shot. :-)

> These days I still act as an adviser to many companies just
> for the fun of it, otherwise I would go crazy. I love people coming to me
> with a problem that they think is insoluble, and then showing them a
working
> prototype in under an hour.

I know the feeling. That's one of the big payoffs of things like MS
Access.The kudos.  When you do something spectaclar in Java, only other Java
coders appreciate it.

> Thanks for the discussion. Much appreciated.

Cheers.

--------------------------------------------------------------
Repent! Quit your job! Slack off!
http://www.users.bigpond.com/pmurray
ICQ: 26066755