-
Notifications
You must be signed in to change notification settings - Fork 55
Unexpected behaviour of DateTime getDay method #731
Comments
It's most likely a timezone issue, can you run with Currently dates are always interpreted as a Date/Time with zero hours/minutes/seconds and are interpreted as instants in a given timezone. This means, it is always preferable to provide explicit timezones to avoid confusion in the request and/or for execution. I would be interested to know if there are requirements for a different behaviour. |
Yes, this is a timezone issue. On reflection I think we need a logical Date object that does not include timezone information for this kind of logic. |
Maybe...what does a date without a timezone mean? If the contract says |
Yes, you are right, there would be an implicit timezone but the object would behave the same regardless of the timezone. So if you call getDay on "2020-01-02" then you will always get 2 regardless of timezone. |
When the getDay method is called in ergo on a DateTime from a request that was created using the String "2020-01-02" the value returned is 1 rather than 2.
To Reproduce
Run 'cicero trigger' on the attached smart clause template.
Expected behavior
Based on the contract logic I would expect 2 to be returned and no payment obligation to be raised. In fact a payment obligation is raised.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Additional context
This was running in the New York locale and this may be a timezone issue.
The text was updated successfully, but these errors were encountered: