The Daily WTF: Curious Perversions in Information Technology

2014-02-04 Reply Admin

Jeremy:
Geoff:
Digicate:
I don't see any need to alter the hours.
Plus I think you can use utcNow.format("Ymdh") ??

My guess would be he needs to check for the archive file after its closed, the camera software probably closes and renames its archive files every hour or something. So if he runs at 23:00 he probably needs to be looking for a file named for the 22:00 hour. Otherwise it might be a full hour before the monitor discovers the video camera's have failed.

I'm thinking the answer is simper than that. If you're saving a file at 11pm it's the video from 10pm to 11pm (or 10:59:59). Granted they could just remember that the 2014020323 file is in fact for 22-23, but it makes slightly more sense to name it with the start time.

So when the camera switches files at 11 PM, using the expertly-crafted code:

string fileName = videoPath + "\" + utcNow.Year + utcNow.Month.ToString("00") + utcNow.Day.ToString("00") + (utcNow.AddHours(1).Hour).ToString("00") + "." + ConfigurationManager.AppSettings["VideosExtension"];

it then produces the similar behavior of writing to 2014020300.avi; brillant!

Of course some questions that might help clear things up: At what time does the camera determine a given hour's video file's filename? At what time does this file become available in the place where the monitoring software can examine it?

The cameras' software was developed by the company that made the camera, so we can assume that there is no changing the logic. It seems reasonable to assume from the context that the time that the camera determines the file name is the beginning of the hour (when it starts recording that hour's video), but the time that this file becomes available is the end of the hour (after the recording software has switched to the new hour's file, after the beginning of the next hour). So the monitor has to check for the previous hour's file thus addHours(-1) is entirely accurate.

2014-02-04 Reply Admin

Walky_one:
Geoff:
Seriously in a situation like better just to give the files consecutive numbers not only do you avoid these types a problems; you get filenames that will always sort neatly with other tools.

Well... I give you:

Video_98 Video_99 Video_100 Video_101

(and if you tell me "You just have to prefix the zeroes of course". The I tell you "As soon as you tell me the maximum number of digigs... Of Course")

In short: IF you're doing time specific stuff YYYYMMDDHH is way better!

That case can be solved by using a file manager that does Natural Sorting of file names, like OS X's Finder, Windows' File Explorer, KDE's Dolphin, among others.

Besides in this case the video file names aren't up for modification since they are produced by the camera's software which was developed by the company that makes the cameras.

2014-02-04 Reply Admin

Spencer:
utcNow.AddHours(-1) is correct. However he should be subtracting one from the whole date object, and formatting the output from that.
Subtracting one from the hour at midnight will result in the 23rd hour from the previous day, but since he is only ripping out the HH part the whole date rollover gets lost.

Finally, somebody spotted the elephant in the room.

savar · 2014-02-04 Reply Admin

Datetimes in filenames are fine.:
Why exactly is that an anti-pattern, and not just your opinion on the matter?
There is no technical reason why filenames should not contain datetime info, assuming you use a format which allows alphanumeric sorting.

In addition, if you have a file of "video footage for the security camera in the lobby between 6 and 7 today" then the location of the footage and the datetime it was taken are the actual contents of the file... in this case the datetime isn't meta-data, it's integral to accurately describe the content of the file, and is therefore appropriate to include that info in the title of the file.

To not include such data is to produce a bunch of inconveniently named files, just so that you can feel smug about sticking to some weird (and spurious) file naming principle.

You use that word ("metadata") but you do not know what it means.

The date and time of the video is metadata, not "data". That's about as clear an example of "metadata" as I can think of. The compressed images and keyframes are the "data".

And you completely missed the point: the OS already keeps track of metadata like what time the file was created. Storing that metadata twice only leads to possible inconsistencies, e.g. the OS says it was created at 1pm but the filename indicates it was created at 2pm. Who wins?

If you really want to index a large dataset by time (so that it's efficient to find files that cover certain ranges of days and hours), you should use a real index instead of relying on file metadata.

The Bytemaster · 2014-02-04 Reply Admin

savar:
Datetimes in filenames are fine.:
Why exactly is that an anti-pattern, and not just your opinion on the matter?
There is no technical reason why filenames should not contain datetime info, assuming you use a format which allows alphanumeric sorting.

In addition, if you have a file of "video footage for the security camera in the lobby between 6 and 7 today" then the location of the footage and the datetime it was taken are the actual contents of the file... in this case the datetime isn't meta-data, it's integral to accurately describe the content of the file, and is therefore appropriate to include that info in the title of the file.

To not include such data is to produce a bunch of inconveniently named files, just so that you can feel smug about sticking to some weird (and spurious) file naming principle.

You use that word ("metadata") but you do not know what it means.

The date and time of the video is metadata, not "data". That's about as clear an example of "metadata" as I can think of. The compressed images and keyframes are the "data".

And you completely missed the point: the OS already keeps track of metadata like what time the file was created. Storing that metadata twice only leads to possible inconsistencies, e.g. the OS says it was created at 1pm but the filename indicates it was created at 2pm. Who wins?

If you really want to index a large dataset by time (so that it's efficient to find files that cover certain ranges of days and hours), you should use a real index instead of relying on file metadata.

In this case, however, it would not be wise to rely on the OS metadata. That may not be reliable depending on how this is configured. At least they are presumably using UTC time, but who is to say what happens to the files between the time the file is initialized, the file is closed, and the time the monitor program can actually check the files. Are they even on the same system?

I agree with you in general, but in this specific scenerio, using file names with formatted date makes sense. With the monitor program working so close to the actual time of creation, it also makes sense. For 24-hour video capture that act as an network appliance, this is a good fit.

2014-02-04 Reply Admin

TRWTF is that they need a separate nanny process to see that the primary process is turning its homework in on time.

2014-02-04 Reply Admin

cellocgw:
Just posting to troll that TRWTF is our insane set of units for time - years, days, hours, .. all those nondecimal ... units.

That's why someone invented the industrial minute.

2014-02-04 Reply Admin

JimM:
faoileag:
... It will always look for the files generated one hour removed. ...
... On February 3rd at 23:05 the monitor will test for 2014020322.avi and will find it. ...

You're assuming the hour in the filename is the save time of the recording. If it's the start time of the recording, the -1 logic is correct i.e. 2014020322.avi is the file that starts at 22:00 on 03/02/2014*

*waits for inevitable argument about endianism of dates...

Actually, I was assuming the hour in the filename is the end time of the recording (that was nit-picking, SCNR), but I indeed do not think that the start time is meant. I think it makes more sense to take the end time ("contains footage up to the hour part in the filename"), but that might just be me.

The reasoning goes like this: Ted thinks c#'s utcNow.Hour() returns a 1-based integer (in a.m./p.m. you don't have 0:42 a.m. if I'm right).

So he automatically decreases the number by one in much the same way that you have to increase utcNow.getMonth() by one in Javascript because it's zero-based.

Would he really wanted to get the previous hour of utcNow, he would have created a second variable like utcNowMinusOne, since by just decreasing the hour part, he misses the rollover at midnight.

True, his attempt to fix it could be read as an attempt to create a filename based on now minus one hour, but then Eric's initial reaction, telling him that Hour returns a zero-based number, for me at least is a strong indication that this really is just a off-by-one wtf.

herby · 2014-02-04 Reply Admin

One may think that using dates in file name is "overkill", since files already have this "metadata" already. Please don't do this. The simple fact that the file was copied/moved to another location, or (more subtle, archived), this meta data can change and it isn't that visable to the common user unless they dig for it.

So, yes having the date in the file name is a "good thing" since you can do all sorts of things. Most (if not all) file systems access files by their name, not their meta data, and it is this name that is reported in a simple directory walk.

Of course given that, sometimes my camera weirds out and doesn't get the time correct, and then starts in December of 1969 (I'm the USA), and I do need to change the file name to something based on the metadata, but I do this quite quickly and all is well in the world.

Quick moral: While it may seem simple, Time isn't when you consider all the variables/operators that can be done to timestamps. Even sorting on month names can be a bit troublesome. Your system should have proper time functions. USE THEM and avoid the WTF moment!

chubertdev · 2014-02-04 Reply Admin

Am I the only one that thinks that the person that created the format Date("now -1h") probably eats paste?

chubertdev · 2014-02-04 Reply Admin

Geoff:
Digicate:
I don't see any need to alter the hours.
Plus I think you can use utcNow.format("Ymdh") ??

My guess would be he needs to check for the archive file after its closed, the camera software probably closes and renames its archive files every hour or something. So if he runs at 23:00 he probably needs to be looking for a file named for the 22:00 hour. Otherwise it might be a full hour before the monitor discovers the video camera's have failed.

The TWTF is the anti-pattern of naming files with dates. The filesystem already keeps track of cdate, mdate, and often atime. Seriously in a situation like better just to give the files consecutive numbers not only do you avoid these types a problems; you get filenames that will always sort neatly with other tools. If you are really really worried about losing the filesystem metadata somehow, then just append the files name and data to CSV file or database somewhere at create time.

/trout Geoff

Semantic information in the filename is a really, really good idea. Not having it would be the anti-pattern. No, not an anti-pattern, it'd be more of a WTF.

2014-02-04 Reply Admin

moltonel:
who wouldn't prefer Date("now -1h").format("YYYYMMDDHH") ?

I certainly wouldn't prefer "now -1h"... for common use cases, that means converting numbers to a string for the desired operation, which then internally has to be parsed back into numbers. I'd go with Date.now().subtract(1, TimeUnit.HOUR).("YYYYMMDDHH")... something like that.

2014-02-04 Reply Admin

The real TRWTF is Americans trying to sing Auld Lang Syne.

chubertdev · 2014-02-04 Reply Admin

usitas:
The real TRWTF is Americans trying to sing Auld Lang Syne.

TRWTF is you incorrectly inferring that this story takes place in America.

eViLegion · 2014-02-04 Reply Admin

savar:
Datetimes in filenames are fine.:
... in this case the datetime isn't meta-data, it's integral to accurately describe the content of the file, and is therefore appropriate to include that info in the title ...

You use that word ("metadata") but you do not know what it means.

The date and time of the video is metadata, not "data". That's about as clear an example of "metadata" as I can think of. The compressed images and keyframes are the "data".

And you completely missed the point: the OS already keeps track of metadata like what time the file was created. Storing that metadata twice only leads to possible inconsistencies, e.g. the OS says it was created at 1pm but the filename indicates it was created at 2pm. Who wins?

If you really want to index a large dataset by time (so that it's efficient to find files that cover certain ranges of days and hours), you should use a real index instead of relying on file metadata.

I think if you reread my original post (yes that's me) that I clearly do know and understand what metadata is. As you can see, I was pointing out that in THIS case, that datetime metadata is not just metadata but is also an appropriate part of the title of the video document.

If these videos were "fun stuff I did on my holiday" then I would grant you that datetime stuff was just metadata.

But the point of these videos is that they ate footage of a location during a specific time period therefore the metadata ceases to be merely metadata about when something happened to occur, because it is in addition now a primary descriptor of the data.

OS concerns are basically irrelevant, except to note that specialist hardware may have delayed transmission of the video to the storage medium, thereby potentially introducing a systematic error into the metadata stored by the OS.

Addendum (2014-02-04 17:17): ^you'll see that

*are

abarker · 2014-02-04 Reply Admin

chubertdev:

usitas:
The real TRWTF is Americans trying to sing Auld Lang Syne.
TRWTF is you incorrectly inferring that this story takes place in America.

The Story ...:
The ball had just dropped ... the new monitoring program lit up like Times Square.

While not conclusive, there does seem to be a strong indication. The first paragraph mentions that the ball just dropped and that the system crapped out at midnight. The most well known ball drop is in New York City, New York, USA. Then there's the reference to Times Square, which is also in New York City, New York, USA, last I checked.

Coyne · 2014-02-04 Reply Admin

Not Santa:
JimM:
Steve The Cynic:
Actually, we don't know that. He might have *meant* that it was only *The* WTF, and not The *Real* WTF.

But what he wrote was "The TWTF". So ... the True WTF perhaps? Do we have a believer in our midst?

The THE WTF? It's so definite it needs two definite articles?

Any other options? ;)

Obviously it's "The TIME WTF", duh

Actually, my vote goes to "The TOTAL WTF".

2014-02-04 Reply Admin

Coyne:
Actually, my vote goes to "The TOTAL WTF".

The Terrible WTF?

Like a ninja in the night.... etc.

2014-02-04 Reply Admin

Bill P. Godfrey:
foo AKA fooo:
Bill P. Godfrey:
If this story takes place at midnight in New York, isn't UtcNow going to return a timestamp around 5am?
Unless they mean New York, England. http://en.wikipedia.org/wiki/New_York,_Tyne_and_Wear
New Year != New York (even though both match /^New Y...$/).

Oops....

Ummmm....

I did say "if this story takes place in New York."

article:
The ball had just dropped...New Years....

I assumed Time Squeare too

2014-02-04 Reply Admin

JimM:
faoileag:
... It will always look for the files generated one hour removed. ...
... On February 3rd at 23:05 the monitor will test for 2014020322.avi and will find it. ...

You're assuming the hour in the filename is the save time of the recording. If it's the start time of the recording, the -1 logic is correct i.e. 2014020322.avi is the file that starts at 22:00 on 03/02/2014*

*waits for inevitable argument about endianism of dates...

no it doesn't. It actially starts at 23:00....

If you want an hourly file that starts at time X:00 you simply truncate the minutes.

2014-02-04 Reply Admin

herby:
One may think that using dates in file name is "overkill", since files already have this "metadata" already. Please don't do this. The simple fact that the file was copied/moved to another location, or (more subtle, archived), this meta data can change and it isn't that visable to the common user unless they dig for it.
So, yes having the date in the file name is a "good thing" since you can do all sorts of things. Most (if not all) file systems access files by their name, not their meta data, and it is this name that is reported in a simple directory walk.

Of course given that, sometimes my camera weirds out and doesn't get the time correct, and then starts in December of 1969 (I'm the USA), and I do need to change the file name to something based on the metadata, but I do this quite quickly and all is well in the world.

Quick moral: While it may seem simple, Time isn't when you consider all the variables/operators that can be done to timestamps. Even sorting on month names can be a bit troublesome. Your system should have proper time functions. USE THEM and avoid the WTF moment!

Holy Moley!

2014-02-04 Reply Admin

neminem:
Heh, I found something like that in some internal code I inherited a while back - only it was in a filter on the Month, so nobody had noticed it until December: take the current month, turn it into an int, add one, turn it back into a month. Brillant.

This is not as strange as it looks.

In Javascript, the date object methods return year and date as the correct number, but month as a zero based counter, 0-11.

So new Date(2014, 1, 5) gives the date February 5th 2014, not January.

And if that pattern is reused in another language where months are returned as 1-12, you get your error.

;)

chubertdev · 2014-02-04 Reply Admin

abarker:
chubertdev:

usitas:
The real TRWTF is Americans trying to sing Auld Lang Syne.
TRWTF is you incorrectly inferring that this story takes place in America.

The Story ...:
The ball had just dropped ... the new monitoring program lit up like Times Square.
While not conclusive, there does seem to be a strong indication. The first paragraph mentions that the ball just dropped and that the system crapped out at midnight. The most well known ball drop is in New York City, New York, USA. Then there's the reference to Times Square, which is also in New York City, New York, USA, last I checked.

Not only are there plenty of cities where a ball drops, but there is absolutely zero indication that the article occurs in the same city that the ball dropped in.

It's possible, but nowhere near conclusive.

2014-02-04 Reply Admin

caffeine:
My good friend Rory Jack Thompson once told me always manipulate your date before chopping into pieces...

pjt33:
I have a very strong suspicion that the stuff about the party was invented as part of the TDWTFification, solely to get a cigar into the story.

Enough of this already.

Did you see the article a few days ago? "Thanks Bill!" That's what she said.

Ratchetr · 2014-02-04 Reply Admin

chubertdev:
Not only are there plenty of cities where a ball drops, but there is absolutely zero indication that the article occurs in the same city that the ball dropped in.
It's possible, but nowhere near conclusive.

It doesn't matter if the article occurs in the same city the ball dropped iff it is in fact the NYC ball. The NYC ball drops at 0500 UTC. It doesn't matter if you are sitting in NY, San Francisco or Australia, it's still 0500 UTC.

For the ball drop thing to be true (which, of course, it almost certainly isn't), the ball would need to be in the UTC/GMT timezone. That reduces the set of possible cities where the ball was, does it not?

2014-02-04 Reply Admin

abarker:
chubertdev:

usitas:
The real TRWTF is Americans trying to sing Auld Lang Syne.
TRWTF is you incorrectly inferring that this story takes place in America.

The Story ...:
The ball had just dropped ... the new monitoring program lit up like Times Square.
While not conclusive, there does seem to be a strong indication. The first paragraph mentions that the ball just dropped and that the system crapped out at midnight. The most well known ball drop is in New York City, New York, USA. Then there's the reference to Times Square, which is also in New York City, New York, USA, last I checked.

If it was in the US, the time format would be MMDDYYYYHH.

2014-02-04 Reply Admin

Or Something:
abarker:
chubertdev:

usitas:
The real TRWTF is Americans trying to sing Auld Lang Syne.
TRWTF is you incorrectly inferring that this story takes place in America.

The Story ...:
The ball had just dropped ... the new monitoring program lit up like Times Square.
While not conclusive, there does seem to be a strong indication. The first paragraph mentions that the ball just dropped and that the system crapped out at midnight. The most well known ball drop is in New York City, New York, USA. Then there's the reference to Times Square, which is also in New York City, New York, USA, last I checked.

If it was in the US, the time format would be MMDDYYYYHH.

CBNC -- it would be: HHamMMMDDYYYY or HHpmMMMDDYYYY

chubertdev · 2014-02-04 Reply Admin

Ratchetr:
chubertdev:
Not only are there plenty of cities where a ball drops, but there is absolutely zero indication that the article occurs in the same city that the ball dropped in.
It's possible, but nowhere near conclusive.
It doesn't matter if the article occurs in the same city the ball dropped iff it is in fact the NYC ball. The NYC ball drops at 0500 UTC. It doesn't matter if you are sitting in NY, San Francisco or Australia, it's still 0500 UTC.

For the ball drop thing to be true (which, of course, it almost certainly isn't), the ball would need to be in the UTC/GMT timezone. That reduces the set of possible cities where the ball was, does it not?

So Cuba, Columbia, Chile, etc...?

2014-02-04 Reply Admin

Ratchetr:
chubertdev:
Not only are there plenty of cities where a ball drops, but there is absolutely zero indication that the article occurs in the same city that the ball dropped in.
It's possible, but nowhere near conclusive.
It doesn't matter if the article occurs in the same city the ball dropped iff it is in fact the NYC ball. The NYC ball drops at 0500 UTC. It doesn't matter if you are sitting in NY, San Francisco or Australia, it's still 0500 UTC.

For the ball drop thing to be true (which, of course, it almost certainly isn't), the ball would need to be in the UTC/GMT timezone. That reduces the set of possible cities where the ball was, does it not?

And if it was in Australia, they'd all be eating chocolate and strudel listening to Mozart.

2014-02-05 Reply Admin

Balu:
moltonel:
Russell:
addHours(-1) I laughed out loud at that.

To my non-java-trained eyes, this looks like a reasonable API call.

Well, it's C#, isn't it? And the equivalent to Date("now-1h") in C# is DateTime.Now.AddHours(-1);

If it is C#, then the code would me even more wrong.

HINT: Take a look at the "". IF it was C#, it should read "\" or @"". Else, you'd just be escaping the second ", which I think doesn't make a lot of sense in this context (plus, the rest of the code would just be seen as a string).

2014-02-05 Reply Admin

Hannes:
Balu:
Well, it's C#, isn't it?

If it is C#, then the code would me even more wrong.

HINT: Take a look at the "".

Nicely spotted.

But although the code wouldn't compile as it stands, it probably is C# nevertheless - the ConfigurationManager class used in the building of the string is a very strong indicator.

2014-02-05 Reply Admin

bill:
Ratchetr:
chubertdev:
Not only are there plenty of cities where a ball drops, but there is absolutely zero indication that the article occurs in the same city that the ball dropped in.
It's possible, but nowhere near conclusive.
It doesn't matter if the article occurs in the same city the ball dropped iff it is in fact the NYC ball. The NYC ball drops at 0500 UTC. It doesn't matter if you are sitting in NY, San Francisco or Australia, it's still 0500 UTC.

For the ball drop thing to be true (which, of course, it almost certainly isn't), the ball would need to be in the UTC/GMT timezone. That reduces the set of possible cities where the ball was, does it not?
And if it was in Australia, they'd all be eating chocolate and strudel listening to Mozart.

Astralia or Austria?

2014-02-05 Reply Admin

Datetimes in filenames are fine.:
Geoff:
The TWTF is the anti-pattern of naming files with dates. The filesystem already keeps track of cdate, mdate, and often atime. Seriously in a situation like better just to give the files consecutive numbers not only do you avoid these types a problems; you get filenames that will always sort neatly with other tools. If you are really really worried about losing the filesystem metadata somehow, then just append the files name and data to CSV file or database somewhere at create time.

Why exactly is that an anti-pattern, and not just your opinion on the matter?

There is no technical reason why filenames should not contain datetime info, assuming you use a format which allows alphanumeric sorting.

In addition, if you have a file of "video footage for the security camera in the lobby between 6 and 7 today" then the location of the footage and the datetime it was taken are the actual contents of the file... in this case the datetime isn't meta-data, it's integral to accurately describe the content of the file, and is therefore appropriate to include that info in the title of the file.

To not include such data is to produce a bunch of inconveniently named files, just so that you can feel smug about sticking to some weird (and spurious) file naming principle.

The anti-pattern is that the code is dependent on the file naming pattern, which is totally irrelevant. All we want to do is verify that files are being added in a timely manner. We should not be concerning ourselves with date formats or file extensions or structure whatsoever. Just reserve a folder for the camera and verify that it's being updated.

2014-02-05 Reply Admin

abarker:
chubertdev:

usitas:
The real TRWTF is Americans trying to sing Auld Lang Syne.
TRWTF is you incorrectly inferring that this story takes place in America.

The Story ...:
The ball had just dropped ... the new monitoring program lit up like Times Square.
While not conclusive, there does seem to be a strong indication. The first paragraph mentions that the ball just dropped and that the system crapped out at midnight. The most well known ball drop is in New York City, New York, USA. Then there's the reference to Times Square, which is also in New York City, New York, USA, last I checked.

I simply assumed that "ball had dropped" was a double entendre referring to both New Years at midnight (when the ball drops in New York) and the fact that someone had "dropped the ball" and screwed up their application.

Even if you assume that "the ball had just dropped" is literally referring to the movement of the ball in Times Square, it still could be anywhere in that time zone, not necessarily New York City.

And even if you assume that it literally meant that they were in New York City, that's undoubtedly part of the anonymization process anyway.

2014-02-05 Reply Admin

nmclean:
Datetimes in filenames are fine.:
Geoff:
The TWTF is the anti-pattern of naming files with dates. The filesystem already keeps track of cdate, mdate, and often atime. Seriously in a situation like better just to give the files consecutive numbers not only do you avoid these types a problems; you get filenames that will always sort neatly with other tools. If you are really really worried about losing the filesystem metadata somehow, then just append the files name and data to CSV file or database somewhere at create time.

Why exactly is that an anti-pattern, and not just your opinion on the matter?

There is no technical reason why filenames should not contain datetime info, assuming you use a format which allows alphanumeric sorting.

In addition, if you have a file of "video footage for the security camera in the lobby between 6 and 7 today" then the location of the footage and the datetime it was taken are the actual contents of the file... in this case the datetime isn't meta-data, it's integral to accurately describe the content of the file, and is therefore appropriate to include that info in the title of the file.

To not include such data is to produce a bunch of inconveniently named files, just so that you can feel smug about sticking to some weird (and spurious) file naming principle.

The anti-pattern is that the code is dependent on the file naming pattern, which is totally irrelevant. All we want to do is verify that files are being added in a timely manner. We should not be concerning ourselves with date formats or file extensions or structure whatsoever. Just reserve a folder for the camera and verify that it's being updated.

As opposed to being dependent on some arbitrary counter? You have to name it something. I agree with other people, the date isn't superfluous nonsense here. It's the primary/perfect descriptor of what the video is. This way when Eric's boss wants the copy of the video from 4am 2 months ago sent somewhere there's no worrying about the date being lost. If you pull a backup, copy them around, and so on and so forth, there's no risk of losing the only piece of information that actually identifies what the hell v34900930.avi is because your whole operation is now dependent on a date the OS made up.

On top of all of that, there's no reason NOT to name it with dates either. Yeah, he efed it up, but he could have effed up anything. A counter can reset too (a la the 12/1969 date "problem"), or even worse, you could actually check what files are in the folder and increment the last one, so every time they're archived you get 000000.avi again.

2014-02-05 Reply Admin

eViLegion:
But the point of these videos is that they ate footage of a location *during a specific time period* therefore the metadata ceases to be merely metadata about when something happened to occur, because it is in addition now a primary descriptor of the data.

In other words... metadata.

eViLegion · 2014-02-05 Reply Admin

nasch:
eViLegion:
But the point of these videos is that they ate footage of a location *during a specific time period* therefore the metadata ceases to be merely metadata about when something happened to occur, because it is in addition now a primary descriptor of the data.

In other words... metadata.

I never said it wasn't metadata, I said that it was more than just metadata... It is of elevated importance in this case.

Also, "in the words" suggest that a primary descriptor and metadata are synonymous. Which is clearly false. One is a superset containing the other.

2014-02-05 Reply Admin

eViLegion:
nasch:
eViLegion:
But the point of these videos is that they ate footage of a location *during a specific time period* therefore the metadata ceases to be merely metadata about when something happened to occur, because it is in addition now a primary descriptor of the data.

In other words... metadata.

I never said it wasn't metadata, I said that it was more than just metadata... It is of elevated importance in this case.

Also, "in the words" suggest that a primary descriptor and metadata are synonymous. Which is clearly false. One is a superset containing the other.

Will you people please just quit bickering about whether or not metadata belongs in the filename?

THE FILENAME IS METADATA.

2014-02-05 Reply Admin

QJo:
Or Something:
abarker:
chubertdev:

usitas:
The real TRWTF is Americans trying to sing Auld Lang Syne.
TRWTF is you incorrectly inferring that this story takes place in America.

The Story ...:
The ball had just dropped ... the new monitoring program lit up like Times Square.
While not conclusive, there does seem to be a strong indication. The first paragraph mentions that the ball just dropped and that the system crapped out at midnight. The most well known ball drop is in New York City, New York, USA. Then there's the reference to Times Square, which is also in New York City, New York, USA, last I checked.

If it was in the US, the time format would be MMDDYYYYHH.

CBNC -- it would be: HHamMMMDDYYYY or HHpmMMMDDYYYY

And in RFC822ia it would be: Www, Mmm DD HH:MM:SS YYYY

Not sure why they didn't swap hours and minutes as well.

2014-02-05 Reply Admin

anonymous:
THE FILENAME IS METADATA.

I've metabill but I've never metadata. I've only seen him on TV.

chubertdev · 2014-02-05 Reply Admin

FWIW, networks will replay the ball dropping in NYC in other time zones. I get to see it here on the left coast 3 hours after it actually happened.

2014-02-06 Reply Admin

Geoff:
The TWTF is the anti-pattern of naming files with dates. The filesystem already keeps track of cdate, mdate, and often atime. Seriously in a situation like better just to give the files consecutive numbers not only do you avoid these types a problems; you get filenames that will always sort neatly with other tools. If you are really really worried about losing the filesystem metadata somehow, then just append the files name and data to CSV file or database somewhere at create time.

I think you are in the minority here. Why add complexity to a solution by adding a separate set of meta data in a database/csv file if you can just look at the directory? It seems so unecessary

2014-02-06 Reply Admin

anonymous:
THE FILENAME IS METADATA.

Most of you guys don't understand the word nuance, do you?

2014-02-06 Reply Admin

Hannes:
Balu:
moltonel:
Russell:
addHours(-1) I laughed out loud at that.

To my non-java-trained eyes, this looks like a reasonable API call.

Well, it's C#, isn't it? And the equivalent to Date("now-1h") in C# is DateTime.Now.AddHours(-1);

If it is C#, then the code would me even more wrong.

HINT: Take a look at the "". IF it was C#, it should read "\" or @"". Else, you'd just be escaping the second ", which I think doesn't make a lot of sense in this context (plus, the rest of the code would just be seen as a string).

Well, if it was Java, method names would start with small letters. From the use of ConfigurationManager you can easily guess that it's C# and I just suspect that some automatic formatting in the forum software swallows the second "".

2014-02-06 Reply Admin

You're the first to bring up such a nuance.

2014-02-06 Reply Admin

Instead of tedious discussions about using date formats in filenames (all these problems were solved eons ago, do some googling if you need to do it to avoid all this stuff), how come nobody has noticed the really real WTF?

WTF were you doing spending New Year's Eve IN THE OFFICE AT WORK??!!!

2014-02-07 Reply Admin

chubertdev:
usitas:
The real TRWTF is Americans trying to sing Auld Lang Syne.

TRWTF is you incorrectly inferring that this story takes place in America.

Maybe the inferrence is because they are not handing out Cuban cigars?

2014-02-07 Reply Admin

This guy:
Geoff:
The TWTF is the anti-pattern of naming files with dates. The filesystem already keeps track of cdate, mdate, and often atime. Seriously in a situation like better just to give the files consecutive numbers not only do you avoid these types a problems; you get filenames that will always sort neatly with other tools. If you are really really worried about losing the filesystem metadata somehow, then just append the files name and data to CSV file or database somewhere at create time.

I think you are in the minority here. Why add complexity to a solution by adding a separate set of meta data in a database/csv file if you can just look at the directory? It seems so unecessary

Because when you copy a file or folder (such as, say, during a backup) the Date Created of the new file is Now?

2014-02-07 Reply Admin

Balu:
Hannes:
Balu:
moltonel:
Russell:
addHours(-1) I laughed out loud at that.

To my non-java-trained eyes, this looks like a reasonable API call.

Well, it's C#, isn't it? And the equivalent to Date("now-1h") in C# is DateTime.Now.AddHours(-1);

If it is C#, then the code would me even more wrong.

HINT: Take a look at the "". IF it was C#, it should read "\" or @"". Else, you'd just be escaping the second ", which I think doesn't make a lot of sense in this context (plus, the rest of the code would just be seen as a string).
Well, if it was Java, method names would start with small letters. From the use of ConfigurationManager you can easily guess that it's C# and I just suspect that some automatic formatting in the forum software swallows the second "".

If it was the forum software swallowing the second , then this would be TRWTF, right?

chubertdev · 2014-02-10 Reply Admin

CigarDoug:
chubertdev:
usitas:
The real TRWTF is Americans trying to sing Auld Lang Syne.

TRWTF is you incorrectly inferring that this story takes place in America.
Maybe the inferrence is because they are not handing out Cuban cigars?

If they were handing out Cohibas, it would definitely be NYC.

The Midnight Cowboy Coder

Leave a comment on “The Midnight Cowboy Coder”