Dates ought to be day-light-savings-aware

Description

See http://blog.adamcameron.me/2015/08/lucee-uncontrolled-language-design.html

Lucee's date objects are not DLS-aware. For example 2016-03-27 01:01:00 does not exist as a time in the UK. So it should be invalid when calling createDateTime(). However this works:

illegalTime = createDateTime(2016, 3, 27, 1, 01, 00);

ColdFusion - correctly - raises an exception for this.

That time is just as illegal as Feb 32 or any other nonsense datetime.

Activity

Show:

Adam Cameron 15 August 2015 at 07:38

problem is that if we adapt the acf behavior for example scheduled task running between 1 and 2 on Britain time will then break once a year.

No, they'd break once. Because unless you're a muppet, you'd then go "oh, yeah, of course" (or someone else does when you ask why on a forum), and you change the time. And thereafter you don't do that ever again.

In reality though, we (the dev community) just understand these things, and don't schedule tasks in that window, I think.

But anyway, yeah: I don't see there are being a problem here as long as the difference is documented.

Michael Offner 15 August 2015 at 06:37

I have removed all comments not related to this ticket directly, that are pure conversation about time zone in general.

The problem with this ticket is that Lucee Interprets createDateTime(2016, 3, 27, 1, 01, 00);
as 2016/3/27 2:01:00 when the environment timezone is for example European/London.
Acf throws an exception in this case.

problem is that if we adapt the acf behavior for example scheduled task running between 1 and 2 on Britain time will then break once a year.

So document that this simply works different than acf in this edge case maybe the better option.

Adam Cameron 13 August 2015 at 16:48

Yeah, sorry, I thought the " in the UK" implied fairly clearly that you would need your TZ to be UK before testing 😉 There's no point testing something specific to the UK TZ on a machine that's in the States or Switzerland. However you could test with the equivalent time for when DLS ends in Switzerland perhaps? Anyway: you get the idea.

Bearing our other conversation about "whether DateTimes should be TZ-aware", it seems that ColdFusion DateTimes are TZ aware. In that Lucee ones are not (it would seem), this might be a problem for you to deal with. Accordingly it might be better to just document it as an incompat?

Michael Offner 13 August 2015 at 16:30

testcase that shows the issue independent of the environment by setting the the timezone in advance
https://github.com/lucee/Lucee4/commit/b9a1504018a603ca3daaa2869fc827c11faba688

Michael Offner 13 August 2015 at 15:52

i was raising "need more details" because i was not able to reproduce on trycf and my machine.

But after thinking about it a little bit further I know why it works not on your machine (with ACF) but on my machine and on trycf.
Problem is that you have a different timezone definition in your enviroment (ACF and Lucee) than tycf or i have.
to convert the numbers provided to the function createDateTime, ACF is using the environment timezone to do so.
so in the UK your date provided is invalid, but it is perfectly fine in Switzerland or the US.
http://www.timeanddate.com/time/change/switzerland/bern
http://www.timeanddate.com/time/change/usa/new-york

then we switch from 2am to 3am on different dates.

in Lucee btw this function support that you can define the timezone as argument or you can simply set it before with "setTimeZone"

Fixed

Assignee

Michael Offner

Reporter

New Issue warning screen

Before you create a new Issue, please post to the mailing list first https://dev.lucee.org

Once the issue has been verified, one of the Lucee team will ask you to file an issue

Affects versions

Priority

Created 12 August 2015 at 07:58
Updated 30 April 2024 at 18:29
Resolved 30 April 2024 at 18:29

Flag notifications