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
