Weird CreateDateTime() Error

[Guest]

Works … <cfoutput>#createdatetime(2011,3,13,3,0,0)#</cfoutput>

Doesn’t work … <cfoutput>#createdatetime(2011,3,13,2,0,0)#</cfoutput>  … it is only hour 2 on March 3, 2011 that errors.

** Does Adobe have something against March 3rd, 2011 @ 2 am?

[Adam Cameron.]

If you're in most parts of the USA, there is no 2am on 13/3/2011 (umm... "3/13/2011" to you, I guess). Daylight saving kicks in after the end of 01:59, and the time becomes 03:00.

--

Adam

[Guest]

Ah, I understand the Daylight Savings but don't understand why it flat out errors.  Am I suppose to catch this error?

*** The isDate() will validate before using CreateDateTime().

[Adam Cameron.]

It errors because that time simply doesn't exist.  Just like there's no 37 o'clock that day (and you'd expect createDate(2011, 3, 13, 37, 0, 0) to error, yes?); there's no 2 o'clock either.  So either don't try to create that time, or if you must then - yes - you need to try/catch it.

--

Adam

[tooMuchTrouble]

On 12/1/2010 11:52 PM, jb_aggie said:

Ah, I understand the Daylight Savings but don't understand why it flat out errors. Am I suppose to catch this error?

handling timezones is a massive pain. in your case if you're building the

datetimes from dateparts build a date from year,day,month parts then add the

hours w/dateAdd(). cf should flop over hat ate to the server tz whether you like

it or not.

if your app fiddles w/datetimes like this you might think about storing epoch

offsets instead of datetimes.

[Micah_Brown]

One thing you mentioned is that this time doesnt occur in most places since most states, counties observe daylight saving time (which I hope they get rid of one day). But what is this was meant to run in one of those places that 'doesnt' observe this ridiculous thing?  Are they basically SOL?

Just curious.

[Adam Cameron.]

It's based on the TZ of your server, so provided you cater for whatever rules occur in your TZ (which are published, and easy to find), then it doesn't matter what the rules are in other TZs.

If you need to mark off hourly time intervals during a given day (which sounds like what the OP might be doing), then use dateAdd() to add the hours, instead of createDateTime().  That way CF (or more to the point, the JVM) will do the adjustment for you.

As for the benefits of DLS... I'd much rather - in the middle of summer - that the sun came up @ 5:45 and set @ 21:15 (as it does here with DLS) than having it at 4:45 and 20:15.  Just like most people, I get more out of the sunshine in the evening than in the morning (where I am desperately hiding from it, trying to get a wee bit more sleep!).  Other than for a minority of people who have schedules controlled by nature rather than a clock (like farmers), it's - on the whole - better this way.  And it's not exactly hard to deal with.  What's your problem with it?

--

Adam

[Guest]

I agree with Adam. Daylight savings time should be all the time here in the U.S. The only time I like normal time is when the time initially falls back and we get an extra hour of sleep (sort of).

[Micah_Brown]

There are quite a bit of people that have to adjust themselves to the new time and it takes several days or even a week get get back into their routines.

Everyone is different on how they view this. Personally I don't have a problem with leaving the day as it is and I would rather not be bothered with changing all the clocks (their are still quite a few clocks that don't automatically adjust).

To each his own right?

[Adam Cameron.]

To each his own right?

Sure, but you weren't exactly espousing "to each his own", were you?  You were saying you wished they'd get rid of it.  Which would effect more people than just you 😉

Anyway, that's just semantics, and I mean nothing by it.  Nor that I was suggesting there was anything wrong with your position, I was just offering a different (ie: my ~) perspective on it, and wondering - for the sake of conversation and no other reason - what your rationale was.

--

Adam