Convert DST to STD Time on the Fly?

  • Thread starter Thread starter croy
  • Start date Start date
C

croy

For a database in the U.S. that sees a lot of analysis, I've
decided that a little reduncancy is a good thing.

Our field crews record DST when it is in effect, but our
analysts would usually like to use Standard Time. So I've
decided that it's better to have a field for each, and have
the form code do the conversion at data-entry time.

But I've taken several runs at coding this, and always get
to a point where I realize my approach isn't going to work.

I'm guessing others have preceded me.

Anyone care to throw something in here?
 
Instead of saving both the Local DST and Local standard Time, why not just
save only UTC time. Now you have a absolute universal time for all events
that you have recorded and can easily do all of the date/time math without
having to worry about differing Time Zones and or weather DST applies.

Just my $.02

Ron W
 
Instead of saving both the Local DST and Local standard Time, why not just
save only UTC time. Now you have a absolute universal time for all events
that you have recorded and can easily do all of the date/time math without
having to worry about differing Time Zones and or weather DST applies.

Just my $.02

Ron W


Your comment is appreciated, and that idea certainly has its
up side. We had discussed that option, and decided that
whether the field crews make the conversion in the field, or
the data-entry clerks make the conversion on the fly, there
are bound to be more errors introduced than if everybody
just puts down the local time as they read it off their
watches (or off the paper forms), and let a routine in the
db handle the conversion. That worry could be mitigated
somewhat by putting a space on the paper forms for both time
formats, and have the field crews fill in the UTC boxes when
they get back to the office, but we are really up against
the wall for space on the paper forms, and there would
probably still be some errors made (in our experience, the
more mundane the task, the higher the error rate).

--
croy

 
Paper, Pencils, Watches! It never occurred to me that you were collecting
the data with a pencil and paper. I was assuming that you collected the
data using computers, laptops, PDA's etc. I agree that to keep errors to a
minimum you should absolutely collect the time from the users using whatever
is most convenient for them. Perhaps you will be able to do a conversion at
the time that data gets entered into your system.

Depending on the importance of the data you are collecting, and the number
of collectors involved, it may be cost effective to buy some cheap PDA's and
automating the whole process so it becomes paperless. It surely would make
for a less error prone system.

Ron W
croy said:
Instead of saving both the Local DST and Local standard Time, why not just
save only UTC time. Now you have a absolute universal time for all events
that you have recorded and can easily do all of the date/time math without
having to worry about differing Time Zones and or weather DST applies.

Just my $.02

Ron W


Your comment is appreciated, and that idea certainly has its
up side. We had discussed that option, and decided that
whether the field crews make the conversion in the field, or
the data-entry clerks make the conversion on the fly, there
are bound to be more errors introduced than if everybody
just puts down the local time as they read it off their
watches (or off the paper forms), and let a routine in the
db handle the conversion. That worry could be mitigated
somewhat by putting a space on the paper forms for both time
formats, and have the field crews fill in the UTC boxes when
they get back to the office, but we are really up against
the wall for space on the paper forms, and there would
probably still be some errors made (in our experience, the
more mundane the task, the higher the error rate).
 
Paper, Pencils, Watches! It never occurred to me that you were collecting
the data with a pencil and paper. I was assuming that you collected the
data using computers, laptops, PDA's etc. I agree that to keep errors to a
minimum you should absolutely collect the time from the users using whatever
is most convenient for them. Perhaps you will be able to do a conversion at
the time that data gets entered into your system.

Depending on the importance of the data you are collecting, and the number
of collectors involved, it may be cost effective to buy some cheap PDA's and
automating the whole process so it becomes paperless. It surely would make
for a less error prone system.

Thanks for the reply, Ron.

Yes, PDAs would be wonderful, but... some of our clerks are
in boats, some on shore, and some in kayaks. Too much water
for electronics! We can't even keep up with the cell phone
"oopses". The cost of PDAs and their continual replacements
would put us out of business!

So I need to come up with a routine for converting times.
I'm just stumped on things like "the second Sunday" ... and
such.
 
Back
Top