What steps will reproduce the problem?
1. Set the computer date to 2013-10-20 and Time Zone to "Brasilia Summer Time"
(City: São Paulo - Brazil)
2. When creating a Date instance, the browser's console should output something
like:
> new Date
Sun Oct 20 2013 19:50:18 GMT-0200 (BRST)
3. With Closure Library loaded, create a new instance of goog.date.Date:
> today = new goog.date.Date(2013, 9, 20)
4. In a goog.date.Date object, I'm expecting that getTime() will always return
a timestamp that refers to the first second of that day in the current
timezone. Let's check this:
> new Date(today.getTime())
Sun Oct 20 2013 01:00:00 GMT-0200 (BRST)
Yep, that seems correct, as Oct 20 in this timezone starts at 1am.
5 Now I'm going to add an interval of one day and check what getTime() returns:
> today.add(new goog.date.Interval(goog.date.Interval.DAYS, 1))
> new Date(today.getTime())
Mon Oct 21 2013 01:00:00 GMT-0200 (BRST)
Hmm... this is not exactly what I'm expecting.
What is the expected output? What do you see instead?
Even though this is not explicitly mentioned anywhere, goog.date.Date seems to
make a point of using days as the smallest unit (i.e. not considering hours,
minutes, etc).
I was hoping that getTime() would always return a timestamp that points to the
beginning of each day. As Oct 21 starts at 00:00:00, the output should be:
Mon Oct 21 2013 00:00:00 GMT-0200 (BRST)
What version of the product are you using? On what operating system?
Chrome, OS X.
Please provide any additional information below.
One point in favor of that argument is that explicitly setting a date or
passing a Date object (with the time set somewhere in the middle of the day)
will make goog.date.Date always generate a timestamp pointing to the beginning
of the supplied day:
> date = new goog.date.Date(2013, 9, 21)
> new Date(date.getTime())
Mon Oct 21 2013 00:00:00 GMT-0200 (BRST)
0 hours, as expected for most days.
> date = new goog.date.Date(new Date())
> new Date(date.getTime())
Sun Oct 20 2013 01:00:00 GMT-0200 (BRST)
1am, as expected for Oct 20 (starting date of the DST period)
One point against that argument is that you can use setTime to set an arbitrary
timestamp in the goog.date.Date object. Differently from instantiation, in that
case it won't force the timestamp to be as close as possible to 0 hours:
> date = new goog.date.Date(2013, 9, 21)
> new Date(date.getTime())
Mon Oct 21 2013 00:00:00 GMT-0200 (BRST)
> date.setTime(date.getTime()+3600*2*1000)
> new Date(date.getTime())
Mon Oct 21 2013 02:00:00 GMT-0200 (BRST)
---
So, is this really a bug?
In my opinion it would be more interesting if goog.date.Date could behave in a
more constraining way, always forcing timestamps to be set at the beginning of
each day. If you want more degree of freedom, you could always use
goog.date.DateTime.
If this can't be done due to backwards compatibility or something, I'd suggest
adding a new class (like goog.date.ConstrainedDate) so that users can at least
be aware that goog.date.Date might not be exactly what they're looking for.
Original issue reported on code.google.com by alo.and on 21 Oct 2013 at 11:13
Original issue reported on code.google.com by
alo.andon 21 Oct 2013 at 11:13