Comments (10)
I don't remember exactly why this was added really. This is what I got from the blame: cbde1b5
I guess it's trying to normalize the timezone. I'm happy to make a change if needed.
from cron-expression.
It appears we can maybe work around it on our end as well by passing a string representation instead of a DateTime object, though it does seem intuitively like the Timezone of the given DateTime object should be respected.
from cron-expression.
Maybe I'm wrong there. Here is the PR someone is working on our side (laravel/framework#7636) ... personally I kind of wonder if it should be fixed over here though.
from cron-expression.
I agree it should be fixed here. The library shouldn't be changing the timezone without giving the user the option to specify the timezone it changes to. It's very important to use the correct timezone when checking to see if a cron expression is due since the expressions themselves are not timezone-aware. If you create expressions for GMT-8:00, then the library will always be off by 8 hours if it's converting any DateTimes to GMT/UTC.
I remember a year or so ago, I modified my local copy of the library to accept an optional timezone in the CronExression::factory()
method. That timezone was then used for any ::isDue()
and similar calls. Unfortunately that work has been lost (I had forgotten I did that when I updated to using composer), but I'd be willing to recreate it.
I think it'd be most useful to allow providing a default timezone in the ::factory()
method as well as allowing the user to override that by passing in a DateTime with the appropriate timezone set in ::isDue()
and similar. If no default timezone is supplied, then the system's default is used where necessary.
I could probably work on this this weekend, if you'd like.
from cron-expression.
Looks like this is not handled consistently across all of the public API.
getRunDate() does just clone the given date/time if it is a DateTime instance. So, calling getMultipleRunDates() with a properly set up $currentTime will respect the timezone as given on $currentTime.
I remember that was something I was working towards as I also use this to evaluate against different timezones.
My stand is that if a DateTime instance is given, the timezone set in that instance should be used. For strings or 'now' the default timezone should be used.
from cron-expression.
Is there a suggested fix for this? Anything I can do?
from cron-expression.
It can be fixed. We need a PR that removes all of the timezone modifications from the library and any time a DateTime object will be modified, it's cloned.
from cron-expression.
We fixed it on our end for now by passing a string representation of the
time.
On Thu, Mar 26, 2015 at 11:38 AM, Michael Dowling [email protected]
wrote:
It can be fixed. We need a PR that removes all of the timezone
modifications from the library and any time a DateTime object will be
modified, it's cloned.—
Reply to this email directly or view it on GitHub
#78 (comment)
.
from cron-expression.
@mtdowling @dragonmantank - it looks like someone has made a PR for this issue here #115
Any chance of reviewing it - and potentially merging?
I've run into the same issue as @taylorotwell (ironically for inside a Laravel application) that I really need to support custom timezones...
from cron-expression.
This should have been corrected with #134, so closing.
from cron-expression.
Related Issues (20)
- Class \Cron\YearField not found - Referenced in \Cron\FieldFactory HOT 1
- Not support PHP 7.1.9 HOT 4
- Can you release a 1.2.1 tag? HOT 1
- dragonmantank repository: Unclear where to submit issues HOT 1
- Inconsistent behavior with regards to timezones (2.0) HOT 2
- Composer Autoloader - Not Working (>= 1.6.0) HOT 5
- validate cron expression HOT 1
- Mark this as abandoned on packagist HOT 9
- getMultipleRunDates HOT 1
- Wrong every N-month calculate HOT 1
- Incorrect expression HOT 1
- can't read cron expressions for 6 positions HOT 1
- PSA: Tagging of the 1.2.2 branch caused issues with [insert framework or library] HOT 3
- Yii2 yii2mod/yii2-scheduling - InvalidArgumentException: 5 is not a valid position HOT 2
- abandoned package is required HOT 2
- What is this " 5 is not a valid position" HOT 2
- library incorrectly relies on the timezone set in php.ini
- Express week number
- Invalid CRON field value 30 at position 1 HOT 1
- Add static isValid function to CronExpression to allow testing of expressions prior to creation HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cron-expression.