Dating
-
I hope this counts as a subtle bug and can help those encountering something similar. I'm reading in a bunch of data from files. Basically a datetime (dts) and a float value. Because we're talking about 1.3 million records which I read in with several files, create a list of insert queries and execute them by 100 at the time. Everything worked except for some batches. So looking at the errors, it says it runs into a unique constraint (dts is unique). Fine, what value was double then? none. :confused: is my state of mind by now. So I continue looking and print out the failed batches and sure enough there are double values in there. Checking the corresponding files : no doubles. But what does my little eye spy? double dts values start with 3 'o clock and only at the end of march! Daylightsaving (DTS). The bug: I use java's GregorianCalendar and if you don't specify the timezone it will convert the 2:00 until 3:00 to 1 hour +. so 2:30 becomes 3:30 etc... What is strange though, is that there is no warning, no exceptions nothing. Just implicit conversion. Perhaps it is my misunderstanding of the object, but if you encounter something similar, you just might want to check in this direction. PS: I considered this forum to be the replacement of subtle bugs. [EDIT] The solution is to set the timezone to UTC. If you use de SimpleDateFormat class to format the dates to string. This also has a timezome, which you also need to set to UTC to avoid having the date converted. [/EDIT]
V.
-
I hope this counts as a subtle bug and can help those encountering something similar. I'm reading in a bunch of data from files. Basically a datetime (dts) and a float value. Because we're talking about 1.3 million records which I read in with several files, create a list of insert queries and execute them by 100 at the time. Everything worked except for some batches. So looking at the errors, it says it runs into a unique constraint (dts is unique). Fine, what value was double then? none. :confused: is my state of mind by now. So I continue looking and print out the failed batches and sure enough there are double values in there. Checking the corresponding files : no doubles. But what does my little eye spy? double dts values start with 3 'o clock and only at the end of march! Daylightsaving (DTS). The bug: I use java's GregorianCalendar and if you don't specify the timezone it will convert the 2:00 until 3:00 to 1 hour +. so 2:30 becomes 3:30 etc... What is strange though, is that there is no warning, no exceptions nothing. Just implicit conversion. Perhaps it is my misunderstanding of the object, but if you encounter something similar, you just might want to check in this direction. PS: I considered this forum to be the replacement of subtle bugs. [EDIT] The solution is to set the timezone to UTC. If you use de SimpleDateFormat class to format the dates to string. This also has a timezome, which you also need to set to UTC to avoid having the date converted. [/EDIT]
V.
That is a known issue with Java, and Sun (and Oracle) have stated it won't be fixed because "it might break existing programs."
Bill Gates is a very rich man today... and do you want to know why? The answer is one word: versions. Dave Barry Read more at [BrainyQuote](http://www.brainyquote.com/quotes/topics topic_technology.html#yAfSEbrfumitrteO.99)[^]
-
That is a known issue with Java, and Sun (and Oracle) have stated it won't be fixed because "it might break existing programs."
Bill Gates is a very rich man today... and do you want to know why? The answer is one word: versions. Dave Barry Read more at [BrainyQuote](http://www.brainyquote.com/quotes/topics topic_technology.html#yAfSEbrfumitrteO.99)[^]
To be fair, it's not just Java's problem. Once a year, any language/environment/framework/program that uses local time with daylight saving is going to have time ambiguity for an hour and once a year it'll have a nonexistent hour. Using UTC makes a lot of sense. ;P Now, if only they'd address the leap second problem... ;P Cheers, Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
I hope this counts as a subtle bug and can help those encountering something similar. I'm reading in a bunch of data from files. Basically a datetime (dts) and a float value. Because we're talking about 1.3 million records which I read in with several files, create a list of insert queries and execute them by 100 at the time. Everything worked except for some batches. So looking at the errors, it says it runs into a unique constraint (dts is unique). Fine, what value was double then? none. :confused: is my state of mind by now. So I continue looking and print out the failed batches and sure enough there are double values in there. Checking the corresponding files : no doubles. But what does my little eye spy? double dts values start with 3 'o clock and only at the end of march! Daylightsaving (DTS). The bug: I use java's GregorianCalendar and if you don't specify the timezone it will convert the 2:00 until 3:00 to 1 hour +. so 2:30 becomes 3:30 etc... What is strange though, is that there is no warning, no exceptions nothing. Just implicit conversion. Perhaps it is my misunderstanding of the object, but if you encounter something similar, you just might want to check in this direction. PS: I considered this forum to be the replacement of subtle bugs. [EDIT] The solution is to set the timezone to UTC. If you use de SimpleDateFormat class to format the dates to string. This also has a timezome, which you also need to set to UTC to avoid having the date converted. [/EDIT]
V.
V. wrote:
Dating
And there was me hoping to find a match. :^)
Signature construction in progress. Sorry for the inconvenience.
-
V. wrote:
Dating
And there was me hoping to find a match. :^)
Signature construction in progress. Sorry for the inconvenience.
-
BobJanova wrote:
On CodeProject? I don't think so :-D
Depends what you're looking for now, doesn't it? :laugh: :laugh:
-
That is a known issue with Java, and Sun (and Oracle) have stated it won't be fixed because "it might break existing programs."
Bill Gates is a very rich man today... and do you want to know why? The answer is one word: versions. Dave Barry Read more at [BrainyQuote](http://www.brainyquote.com/quotes/topics topic_technology.html#yAfSEbrfumitrteO.99)[^]
-
I hope this counts as a subtle bug and can help those encountering something similar. I'm reading in a bunch of data from files. Basically a datetime (dts) and a float value. Because we're talking about 1.3 million records which I read in with several files, create a list of insert queries and execute them by 100 at the time. Everything worked except for some batches. So looking at the errors, it says it runs into a unique constraint (dts is unique). Fine, what value was double then? none. :confused: is my state of mind by now. So I continue looking and print out the failed batches and sure enough there are double values in there. Checking the corresponding files : no doubles. But what does my little eye spy? double dts values start with 3 'o clock and only at the end of march! Daylightsaving (DTS). The bug: I use java's GregorianCalendar and if you don't specify the timezone it will convert the 2:00 until 3:00 to 1 hour +. so 2:30 becomes 3:30 etc... What is strange though, is that there is no warning, no exceptions nothing. Just implicit conversion. Perhaps it is my misunderstanding of the object, but if you encounter something similar, you just might want to check in this direction. PS: I considered this forum to be the replacement of subtle bugs. [EDIT] The solution is to set the timezone to UTC. If you use de SimpleDateFormat class to format the dates to string. This also has a timezome, which you also need to set to UTC to avoid having the date converted. [/EDIT]
V.
V. wrote:
What is strange though, is that there is no warning, no exceptions nothing. Just implicit conversion.
So now is the time to get the following idea into your head... Timestamps ALWAYS have an associated timezone. If it isn't explicit then it is implicit. So anytime you see a timestamp value you MUST determine how the timezone will be determined. Always. And this has nothing to do with Java. It is true for any programming language and for that matter other types of usage as well.
V. wrote:
So looking at the errors, it says it runs into a unique constraint (dts is unique). Fine, what value was double then?
And there are other things about timestamps as well... The resolution for timestamps is not absolute. Especially across boundaries. One example of that is that the MS SQL Server datetime resolution for milli-seconds is less than that of windows. So you can put a value into SQL Server and get it out with a different millisecond value. Because it isn't absolute relying on it to be unique without quaranteeing the coarseness to be more than a second is probably asking for trouble. And for Java the resolution of java.sql.Timestamp as represented by the base class java.util.Date is SECONDS, rather than nanoseconds as represented by java.util.Date itself. Read the docs on java.sql.Timestamp for specifics.
-
To be fair, it's not just Java's problem. Once a year, any language/environment/framework/program that uses local time with daylight saving is going to have time ambiguity for an hour and once a year it'll have a nonexistent hour. Using UTC makes a lot of sense. ;P Now, if only they'd address the leap second problem... ;P Cheers, Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
V. wrote:
Dating
And there was me hoping to find a match. :^)
Signature construction in progress. Sorry for the inconvenience.
I can't believe it took 4 posts before someone said something. :cool:
Membrane.Inside("Insane");