Paul Hastings wrote: > > that's for one US tz. globally there are plenty of others that follow DST and > these are often a moving target. a recent for instance, australia DST > "normally" > ends march 26, 2:59AM (local time) but got pushed back to april 2nd to > accommodate TV coverage of some international sporting event they hosted. the > point being this isn't something you're probably going to carry around in > your > head & there's nothing in core java you can dip into to find out what tz is > operating in what country (though you can tease out the begin/end dates for a > given tz w/some work). the icu4j lib has a method to get tz by country but > that's a whole LOT of weight to add (and the nifty tz rule bits missed the > latest version, 3.6, anyway). i don;t think you should try "fudging" your way > around this (if that's why you asked about the dates).
Partially yeah... I suppose if you KNEW your server was in a specific timezone with a consistent DST, you could correct for it, but that wouldn't be particularly useful in a distributed application. So my next question is.... is #Now().getTime()# *ALWAYS* going to return the correct UTC time in millseconds since the epoch - no matter what timezone you're in? Rick ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:252665 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
