Flutterby™! : PhDhell 2013-11-04 18:15:06.353689+00

PhDhell

2013-11-04 18:15:06.353689+00 by meuon 3 comments

I'm looking at an XML file of data, and with no apparent reason time for the same thing is expressed as:

<timeStamp>2013-11-04T12:12:18</timeStamp>
<timeStamp>11/4/2013 11:54:40</timeStamp>
<timeStamp>11/4/2013 11:54:41\nAM</timeStamp>

Yes, there is a line feed in that third example. Note the lack of a timezone reference. I understand it's not XML's fault, but it is the fault of whatever magic XML/SOAP-ish library is creating the data and the monkey using it.

The sad realization comes when you realize that dispite there being multiple timestamps for each snippit of data: RequestDateTime, ReadingDateTime, CompletedDateTime that there is not the timestamp of the actual reading that is being exported, which in a few cases is days or weeks old, which is the only really important timestamp there is.

So I have a time specific value, without knowing what time that value was valid/relevant... from a system designed by Engineers and PhD's using Java and Oracle. or at least Engineering/Computer Science students.

It isn't the tools fault, but certain tools seem to be used mostly by certain types of people. What I am absolutely sure of is: This system not only met the original very detailed specification, but passed a certification test against standards.

Yeah, I currently work with a few genuine certified CS grads, and it's amazing how they want data structures in places where it doesn't matter, and don't care for the places it does.

And: Ugh. Dates. ISO8601 or GTFO. I mean, in a pinch I'll let you do RFC822 dates because you're old skool and don't want to update your tools, but...

While personally, I don't like all the variations of ISO8601, it's at least a thoughtfully well defined standard that if used well (include a time zone if apropos, please) solves the issues. Thankfully times are only 24hour.. But I've had serious issues with Midnight being both: "00:00" and "24:00" with the difference being what day they belong to, for the same instant. The STS/IEC62055-41 world solves that issue making 00:00:00 an illegal timestamp, and forcing you to increment past it to 00:01:00 (it only uses minutes in the meter). In other worlds, I have forced 24:00:00 as being invalid, and converting to 00:00:00 and making it the first second of the next day. And there have been long arguments with engineers and billing people that think 00:00:00 is the last second of the previous day and wondering why their SQL selection criteria is invalid.

My arrays are all zero based, 00:00:00 begins the current day, there are 24 hours in a day, thus day += hour % 24; hour %= 24; seems like the only valid way to manage midnight.