In CF8
UTC
UTC
UTC
UTC
Output was:
{ts '2010-03-14 00:00:00'}
UTC Sun, 14 Mar 2010 05:00:00 GMT
{ts '2050-07-01 17:07:46'}
UTC Fri, 01 Jul 2050 21:07:46 GMT
{ts '2010-03-15 00:00:00'}
UTC Mon, 15 Mar 2010 04:00:00 GMT
{ts '2050-07-02 16:07:46'}
UTC Sat, 02 Jul 2050 20:07:46 GMT
> I'm planning on using timezone.cfc for a lot of my calendar-related
> functionality in the future due to these issues:
>
> http://timezonecfc.riaforge.org/
you might want this one instead (i think it's a bit newer). i forget why
somebody else pushed that up there but anyway:
http://www.sustai
On Thu, Apr 22, 2010 at 1:37 PM, Judah McAuley wrote:
>
> I'm planning on using timezone.cfc for a lot of my calendar-related
> functionality in the future due to these issues:
>
It's an excellent resource. I use it a good bit. But as I say, I just wasn't
aware of this particular issue, though
I'm planning on using timezone.cfc for a lot of my calendar-related
functionality in the future due to these issues:
http://timezonecfc.riaforge.org/
Cheers,
Judah
On Thu, Apr 22, 2010 at 10:26 AM, Tom McNeer wrote:
>
> Hi Judah,
>
> Yep. I understand. And the consistency is there. I just didn
Hi Judah,
Yep. I understand. And the consistency is there. I just didn't know that
dateAdd made the adjustment, though I knew Java knew the difference.
And though it may have been discussed earlier on the list, I sure couldn't
find it in all the Googling I did before I posted.
Anyway, now that
The issue has come up before on the list and here is the reasoning:
Take 5 a.m. on the day before DST kicks in. Then 5 a.m. on the day
that DST kicks in. Logically, you'd think that one day had elapsed.
Well, that's true if you are using a day as your unit of measurement,
but that isn't how Java
Okay,
So - it wasn't a JVM issue. Updating it did not change the results.
And Steve was right, in a way. But I still don't understand why it should be
this way.
First, Steve, I understand what you're saying about "whenever you display a
time." But in practice, I'm not displaying a time at all.
bject: Re: DateAdd value different on different servers
Steve,
On Thu, Apr 22, 2010 at 8:47 AM, DURETTE, STEVEN J (ATTASIAIT) <
sd1...@att.com> wrote:
>
> I believe it is doing this because even though you are adding a
specific
> amount of seconds the system automatically knows
Steve,
On Thu, Apr 22, 2010 at 8:47 AM, DURETTE, STEVEN J (ATTASIAIT) <
sd1...@att.com> wrote:
>
> I believe it is doing this because even though you are adding a specific
> amount of seconds the system automatically knows to make adjustments
> based on its time zone or if it uses daylight savin
ignore it.
Steve
-Original Message-
From: Tom McNeer [mailto:tmcn...@gmail.com]
Sent: Wednesday, April 21, 2010 5:13 PM
To: cf-talk
Subject: Re: DateAdd value different on different servers
Thanks for the replies, but mainly they tell me that I've muddied the
water.
Let me try to
On 4/22/2010 4:13 AM, Tom McNeer wrote:
> So - we're not dealing with time zones. We're simply creating date/time
no, you're *always* dealing with tz when it comes to cf datetimes. cf will
always use the server's tz for all datetime operations. dump out the java epoch
for both server's
Wow. Post back after you update. I can't image that there's any real
difference between 6.17 and 6.18, but if there is, I'll gladly update
all of our servers NOW! :)
~|
Want to reach the ColdFusion community with something t
On Wed, Apr 21, 2010 at 5:32 PM, Jason Fisher wrote:
>
> I'd say that earns a WTF.
I'd agree.
> It would appear that one of the servers must
> be adjusting the original CreateDate(), but your output shows that it's
> just not happening that way.
And in the real world, the _one_ server tha
I'd say that earns a WTF. It would appear that one of the servers must
be adjusting the original CreateDate(), but your output shows that it's
just not happening that way. I always thought that the DateAdd() was a
simple math function. What are the differences (if any) in JVM and CF
version
Thanks for the replies, but mainly they tell me that I've muddied the water.
Let me try to be clearer:
I shouldn't have even mentioned the Unix value, because that's not relevant.
Just forget that I'm getting a Unix value completely.
And I definitely should not have shown the time zones, becaus
Two quick things:
1) those times aren't an hour off. EDT should be 4 hours off of UTC
(GMT) and you are showing it as 1 hour, so that is actually a
discrepancy of 3 hours.
2) Java uses its own date/time/timezone system that is independent of
the underlying OS. You can directly invoke the OS date
Looks like one of the servers updated to DST and the others didn't.
Steve
-Original Message-
From: Tom McNeer [mailto:tmcn...@gmail.com]
Sent: Wednesday, April 21, 2010 1:55 PM
To: cf-talk
Subject: DateAdd value different on different servers
There's a simple answer to this one; it's
17 matches
Mail list logo