Hi Patrick,
Thank you for your reply, but I think that there are two problems here. One that may be related the time zone logic and another to the dateAdd() logic when the added period is ‘month’. The latter is what I was trying to report in this post.
I run the the code below:
And obtained these results:
PROBLEM 1
Note the difference between NOW and NOW_UTC. As you can see, it is 4 hours, which is correct at this time of the year between UTC and my local time – Toronto (EDT) time.
What follows shows that a hardcoded date (startng at 00:00:00) is indeed interpreted as a utc time because coverting it to UTC yields the same result as the hardcoded value. However, converting it to Local Time shows a 5-hour difference, not the 4-hour difference between NOW and NOW_UTC.
PROBLEM 2
Part 3 takes a date that starts on Jan 1, 2010 at 00:00:00 and successively adds months to it using the dateAdd(‘month’, N) function. My expectation was that this function, when applied to the the first day of a month, would generate the first day of the Nth month added. So if I start on Jan 1 and add 8 months to it, I should be in Sep 1. As you can see, this is not the case, and although all the times are 00:00:00 (as expected, adding months should not change the date), the dates (mm-dd) are wrong in all the highlighted outputs.
Note that in some cases, the difference is a few days! For example, see what happens after adding 2 months to Jan 1: instead of producing March 1, it produces March 4.
This is why I cannot believe that this is caused by differences between utc and local times. In all likelihood, this a different problem from the one with the time zones shown above.
Hope this helps solve the problems. In my case, Problem 2 has a much higher priority.
Many thanks!
Alex
PS:
As said in the original post, I reported a somewhat related problem a few years ago, although that one was using the PHP server.
