I see my problem still hasn't become clear so I'll try again:
My original question was whether it is possible to format the UTC
representation of a date using the qx.util.DateFormat.format method. The
background of my question is: I want to store date/time patterns inside the
.po translation files so that I can easily localize date formats. I know now
that this is *not* possible with the current DateFormat implementation for
the reasons I pointed out earlier.

An alternative would be to use the TimezoneDate class. But in contrast to
qooxdoo's DateFormat class, the TimezoneDate class doesn't support date and
time patterns (
http://download.oracle.com/javase/1.4.2/docs/api/java/text/SimpleDateFormat.html).
You have to pass a formatting function which doesn't help me in this case.

The whole problem would be solved if the DateFormat class was able to return
a formatted string of the UTC representation of a date object. With the
TimezoneDate class or the Date class's native setUTC... methods you could
easily transform a date to *any* desired time and pass it to
DateFormat.format. Perhaps I will open a bug report on that matter.

By the way: Of course UTC and UTC-0 are actually the same time. With UTC I
mean UTC-0. But the term "timezone" in my view refers to an area on the
earth's surface. And as you know the offset from UTC within that area may
change during the year (daylight saving time). So a timezone might have the
time UTC-0 in winter and UTC-1 in summer.

Thanks for your patience ;)


2010/12/14 thron7 <[email protected]>

> When I said "transform" I wasn't referring to the underlying point in
> time, but, as you put it, to the way it is expressed. But as soon as you
> express epoch milliseconds in a date-time string, you have to settle for
> a time zone, there's no way to avoid that. But you seem to believe that
> there is a date-time representation detached from all time zones. Which
> you call "UTC". Which is not true in my understanding, as this is
> actually UTC-0.
>
> Now if all you've got in terms of date-time is the local representation
> of the time (or the UTC-0 representation, for that matter), you need to
> calculate if you want to express that same point in time in terms of a
> different time zone, taking into account day/month/year borders, leap
> days, asf.
>
> It is fine that you would be contempt with representing any given point
> in time as its UTC-0 date-time string, and this "Zulu time" is fair
> enough to use as a reference. But others might want to express time in a
> different times zone. Maybe you should look at the contrib Derrell
> pointed at.
>
> On 12/14/2010 09:56 AM, Marius Austerschulte wrote:
> > The problem here is: It is not possible to transform a date object to
> > another time zone because internally the date object always uses UTC. I
> > don't want to transform the date object itself because then it would
> > refer to a different point in time. Look at the getTime method of the
> > Date object: getTime returns the number of milliseconds between the
> > desired point in time and midnight on January 1, 1970 (UTC). If you
> > transform that date object the number of milliseconds changes so it
> > would *not* refer to the same point in time anymore which means that
> > date is false.
> > A certain date object denotes one point in time which can be expressed
> > in different ways. Example: The date 2010/12/14 9:00 UTC refers to the
> > same point in time as 2010/12/14 11:00 UTC+2 (or CEST). So if I want to
> > display that date in a certain format I should tell the *formatter*
> > which representation of that one date object to use.
> > In my case I'd like to format a date object like "dd.MM.yyy HH:mm" and
> > display it in UTC. My date object is 2010/12/14 9:00 UTC. My time zone
> > here in Germany is UTC+1 in winter. Then the DateFormat class formats
> > the date like this: "14.12.2010 10:00". However, I want the date to be
> > displayed in UTC so according to your advice I would have to change my
> > date object to 2010/12/14 8:00 UTC to get the desired result from the
> > DateFormat class.
> > This seems to work at first sight, but it does not: Look at the dates
> > Mar 28 2010 00:59 UTC and Mar 28 2010 01:00 UTC. This is the point in
> > time when CET changes to CEST. The DateFormat class formats the first
> > date "28.03.2010 01:59" but the second "28.03.2010 03:00". It is not
> > possible to get, for example, the string "28.03.2010 02:00" from the
> > DateFormat class although this date exists in UTC.
> > You see, date transformation doesn't work here. It's an issue of
> > different representations of one moment in time.
> >
> >
> > 2010/12/14 thron7 <[email protected]
> > <mailto:[email protected]>>
> >
> >     Well, as I wrote, my understanding is that what you call UTC, is
> >     actually
> >     UTC-0 which is, like it or not, a time zone (London time). Adding a
> >     UTC-0
> >     API to some framework class would be of limited usability. More
> >     interesting in my eyes would be an API that allows transformation of
> a
> >     date object to *any* time zone, but YMMV.
> >
> >     T.
> >
> >     >> On 12/13/2010 05:36 PM, Marius Austerschulte wrote:
> >     >> > Hi Alex,
> >     >> > I know that the DateFormat class is for formatting a date. I
> just
> >     >> > wondered why only the local representation of the date can be
> >     >> formatted,
> >     >> > not the UTC representation.
> >     >>
> >     >> I find what you write confusing. Any time, including the local,
> >     can be
> >     >> represented in UTC. Date.getUTCDate and friends provide the
> >     current time
> >     >> for a *specific* time zone, namely UTC-0. Is it this you're
> referring
> >     >> to? Then what you want is a date expressed in this particular
> >     time zone.
> >     >>
> >     >
> >     > I want that date being expressed in its UTC representation. A time
> >     zone is
> >     > an area on the earth's surface which has a uniform time. This time
> is
> >     > computed using an offset from UTC. The offset for a time zone may
> >     differ
> >     > during the year (e.g. the offset for the time zone of London in
> >     winter is
> >     > 0,
> >     > but +1 in summer). So I don't want the time of a certain time zone
> >     but the
> >     > universal time, which is UTC.
> >     >
> >     >
> >     >> > It would be nice if you could get a
> >     >> > formatted UTC representation of the date by using a format
> >     string like
> >     >> > "dd.MM.yyyy" instead of having to build a date string manually
> like
> >     >> > d.getUTCDate() + "." + d.getUTCMonth() + ...
> >     >>
> >     >> But that would require date calculation, which, as Alex
> >     suggested, the
> >     >> DateFormat class is not about. That would require a completely
> >     different
> >     >> class.
> >     >>
> >     >
> >     > Why does it require date calculation? The JavaScript API already
> >     provides
> >     > the methods to get the correct date in UTC, so there wouldn't be
> >     the need
> >     > for any further date calculation by the DateFormat class. I just
> >     want the
> >     > DateFormat.format method (or maybe a potential DateFormat.formatUTC
> >     > method)
> >     > to format that UTC time according to a certain format-string. So
> >     from my
> >     > point of view I can't see a big problem with enhancing the
> DateFormat
> >     > class
> >     > with such a feature.
> >     >
> >
> ------------------------------------------------------------------------------
> >     > Lotusphere 2011
> >     > Register now for Lotusphere 2011 and learn how
> >     > to connect the dots, take your collaborative environment
> >     > to the next level, and enter the era of Social Business.
> >     >
> >
> http://p.sf.net/sfu/lotusphere-d2d_______________________________________________
> >     > qooxdoo-devel mailing list
> >     > [email protected]
> >     <mailto:[email protected]>
> >     > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> >     >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >     Lotusphere 2011
> >     Register now for Lotusphere 2011 and learn how
> >     to connect the dots, take your collaborative environment
> >     to the next level, and enter the era of Social Business.
> >     http://p.sf.net/sfu/lotusphere-d2d
> >     _______________________________________________
> >     qooxdoo-devel mailing list
> >     [email protected]
> >     <mailto:[email protected]>
> >     https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Lotusphere 2011
> > Register now for Lotusphere 2011 and learn how
> > to connect the dots, take your collaborative environment
> > to the next level, and enter the era of Social Business.
> > http://p.sf.net/sfu/lotusphere-d2d
> >
> >
> >
> > _______________________________________________
> > qooxdoo-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to