Spinner control issue

Ignition
1

When using a spinner in date mode there seems to be a bug when a user steps through some of the values.

To replicate this behavior create a spinner, set the Spinner Mode to “Date”. In the propertyChange event handler for the spinner add the following code.

if event.propertyName == "dateValue":
	con = event.source
	dv = str(con.dateValue)
	dm = str(con.dateInMillis)
	print 'dateValue: ' + dv + '\tdateInMillis: ' + dm + '\n'

In preview mode set the value to ‘1:00:00’ then step the hour value down using the arrows and watch the values printed in the console.

This is what I see when doing this (I added line numbers when posting)

1. dateValue: Thu Jan 01 01:00:00 CST 1970	    dateInMillis: 25200000
2. dateValue: Thu Jan 01 00:00:00 CST 1970	    dateInMillis: 21600000
3. dateValue: Wed Dec 31 23:00:00 CST 1969	    dateInMillis: 18000000
4. dateValue: Thu Jan 01 23:00:00 CST 1970	    dateInMillis: 104400000
5. dateValue: Thu Jan 01 22:00:00 CST 1970	    dateInMillis: 100800000
6. dateValue: Thu Jan 01 23:00:00 CST 1970	    dateInMillis: 104400000
7. dateValue: Fri Jan 02 00:00:00 CST 1970	           dateInMillis: 108000000
8. dateValue: Thu Jan 01 00:00:00 CST 1970	    dateInMillis: 21600000
9. dateValue: Thu Jan 01 01:00:00 CST 1970	    dateInMillis: 25200000

Notice lines 3 and 6. When the users sees ‘23:00:00’ in the display the dateInMillis value will be either 18000000 or 104400000 depending on which direction they came from. PLEASE NOTE that line 4 does show the correct value for 23:00:00 but this value just flashes as you are stepping down to 22:00:00. IE when stepping down to 22 from 23 you get 2 property change events with one click.
When the display reads 23:00:00 after stepping down from 0:00:00 the dateInMillis value is definitely incorrect as is the dateValue.

A similar set of circumstances occur for the the value 0:00:00 depending on how you get there.

If you factor out the time offset and convert from milliseconds to hours a display value of 0:00:00 might be indicating 0 hours or 24. The only way to tell is to read the value. The same is true for 23:00:00

2

I have been able to replicate this error, and will submit it to our bug database to see if we can find a permanent fix.

If you need the milliseconds for a given time to be the same no matter which direction you approach from then I would recommend instead of using “dateInMillis” use dateInMillis % 86400000
I picked 86400000 because that is the number of milliseconds in one day, therefore both 18000000 and 104400000 will evaluate to 18000000(a correct number of milliseconds for 23:00:00).

3

Cool!

I hadn’t thought of using modulus to work around the bug. I have been parsing the time out of the dateValue string.

4

I’m not convinced that this is a bug, it’s just that by chopping off the date part of the format and only leaving the time, the date parsing is ambiguous because no date is specified.

The difference in millis for the times you’re looking at is easily explained by looking at the dates - they are a day apart one is Dec 31st, 1969, and one is Jan 1st, 1970.

Both milli times represent 23:00:00, as do countless other values, each for a different day. If you want just the time, I suggest putting the millis through an instance of java.util.Calendar, like this:

from java.util import Calendar cal = Calendar.getInstance() cal.setTimeInMillis(millis) hour = cal.get(Calendar.HOUR_OF_DAY) min = cal.get(Calendar.MINUTE) sec = cal.get(Calendar.SECOND)

Also note that in general, doing your own arithmetic on milli times is not a very safe idea, because you forget about things like leap years, leap seconds, etc and your results will not be consistent. java.util.Calendar takes care of these sorts of things for you.

5

Yeah I get that. I think I left out an important detail though, the Date Format. Notice in my example how as I step down from midnight 1/1/70 to 11PM 12/31/69 and then down to 10PM the date pops back over to 1/1/70.

This behavior only occurs when I have the Date Format set to "H:mm:ss". If it is set to the full date time format then all works as expected. It seems that changing the Date Format property to a time only format has the effect of constraining the control to one date (1-1-1970) except that in those special cases the date actually does change and therefore both the date in milliseconds and the date value are out of line with (what looks like to me) the intended behavior.

6

They may be out of line with what you intuitively expect the behavior to be, but once you omit the date from the format, all bets of the date are off, because the parsing becomes ambiguous. Sometimes it will work chronologically because of how the spinner likes to try and “roll” the value, but then when it parses the text it’ll always try and be Jan 1st.

7

I realize this is an old post, but I was wondering if this is still the case? I have a spinner formatted as a date (h:mm a) so that a user can select an hour and minute, but not a year/month/day.

Originally I thought that this date format would act sort of like a mask (display format), rather than actually throwing away the year/month/day information. Whats the advantage of formatting the underlying data, vs simply formatting the display?

1 Like