I am not sure if this is even possible. I have used the export feature on FB to download Messages and all of the file names are basically a long string of numbers. I've searched all over the web to see if there is a way to decode the file name from FB Msgr files. I am trying to get the Date and Time of when the file was sent from a file name.
As an example, here is one of the file names: "17571372_428718127480452_853371653_o_428718127480452.jpg"
I've tried an Epoch & Unix Timestamp Conversion Tool on each of the sections of numbers with no luck. I happen to know what time and date this specific file was sent, but not the others that I have. SO I am using it as a baseline. The time and date is Mar 26, 2017 5:17:15pm.
Thanks for any help or advice!
Related
I have an ICS generator gzip the results but still the files get VERY large. The ICS format clearly isn't made to contain large number of events. I looked at the spec and there doesn't seem to be a way to create "chunks". For example, have an ICS per month of the year with an "index" file in front or a way to "link" to the previous month which would allow me to do something like:
https://mywebsite.com/calendar => 307 => https://mywebsite.com/calendar/202205.ics
Where https://mywebsite.com/calendar/202205.ics would then link to https://mywebsite.com/calendar/202204.ics, etc.
Are there any of such techniques possible with ICS? That would also make it possible to keep read-only data of past events and the ability to static host all these without the need to every time update it with a new static file.
Is there maybe a different calendar format better suited for this that is still compatible with Google Calendar, Outlook and other popular calendar apps?
I am trying to parse in JAVA a date/time that I receive from an API.
The timestamp I receive looks like this: "Thu Feb 13 12:11:09 IST (Israel) 2014"
I am using Java's SimpleDateFormat, however I do not see anywhere how did the country name, with parentheses, arrive in this string, and how should I parse it.
Is this some standard format I don't know about?
UPDATE:
I am receiving this timestamp from an Android application. The funny thing is the exact same application, running on a different device gives me: "Tue Feb 04 17:36:31 GMT+02:00 2014"
GMT+2 is Israel as well, same timezone, different format... why??
I don't know where android manages the time zone name resources. Anyway, obviously the resource names were changed on this one device (by Google?) with the motivation to avoid duplicates. The abbreviation IST is not unique and can also stand for "Indian Standard Time" which maps to Asia/Colcata instead (while Israel time zone is Asia/Jerusalem).
If you cannot parse "IST (Israel)" then I assume following things: If you parse it by SimpleDateFormat directly on android device then it should probably work. But if you get this string remotely then you can only apply preprocessing of string (filtering out the country) because other devices will not necessarily manage and share the same time zone name resources. You might be able to check directly on android what resources are stored there by calling DateFormatSymbols.getZoneStrings().
Conclusion: You should consider such strings as device-dependent. For data exchange, such formats are not well designed. Instead of using such proprietary formats you should try to use ISO-strings in formats like "yyyy-MM-dd'T'HH:mm:ssXX". Does the API you use offer any alternative format?
I am working with a partner who is producing a delimited file for me. The dates are formatted as:
2013.07.06 AD at 01:00:00 GMT
The other company doesn't really have an IT department, so they can't tell me where the format came from. Assuming it is a standard date format, does anyone know which library or database engine would produce this format without a custom format string?
Thank you in advance.
UPDATE:
The partner in question was able to get an answer. For reasons that make no sense to me, the underlying software, written in Java, explicitly formats the date this way, with the " at " and era and time zone indicators. A rather strange choice for a file that is supposed to be consumed by a computer program with no human interaction - they produce a beautiful, human-reasonable Excel file from the same data.
Anyways, thanks for looking and commenting.
Im using cfspreadsheet to read data from spreadsheets inside one of my applications. I've had a great deal of difficulty dealing with date columns. If I format the cell as date english (NZ) it displays right in the spreadsheet, but when I try to upload it switched the day and month. But If I change the format to a custom "dd/mm/yyyy" format it will upload without a problem.
Why would using the default date formats within the spreadsheet mess up the format when a custom one doesn't? Is there a work around?
I was using the Date Type "*14/03/2001".
The * means that it will:
respond to changes in regional date and time settings that are specified for the operating system.
So it must have been getting turned about by java or CF somewhere along the way. I changed it to the same date mask without the asterisk and the problem stopped occurring.
G'day All
If you create a date item in the plist editor of Xcode or Apple's standalone plist editor you get something of the form <date>2010-05-29T10:30:00Z</date> which is a nice well formed ISO date at UTC (indicated by the "Z"). Because I'm in timezone UTC +10 when that's read into my app & then displayed I get 8:30 PM out, still good. However if that is a time in my timezone it should be <date>2010-05-29T10:30:00+10</date> (replacing "Z" with my timezone offset). All of my attempts at reading such dates into my iPhone app have had the plist rejected as if it is malformed & editing a plist with such a date in Apple's editors changed the "+10" to "Z" without adjusting the time.
Do others think I'm correct in thinking this is a bug in either plist or Xcode? My feeling is that the implementation of ISO date & time in plist is incomplete.
Cheers, Pedro :)
It's not a bug in either. In CoreFoundation (and Foundation), all dates are represented in Zulu time, which is why they are serialized that way. The date is then formatted for display based on the timezone of the device that wishes to display it. Although this is an ISO date string, the only valid time zone for CoreFoundation/Foundation is Zulu time.
If, for some reason, you need to track the time zone that any given date was generated in, you should track this as a separate property. If you need to write an XML property list from somewhere else, you must first convert the date to zulu and then write it out (although the documentation clearly specifies that these keys are for debugging aids/readability only and may change in the future). This makes plists a decent way to serialize data between two Cocoa/CoreFoundation applications, but a less suitable way of serializing data between a Cocoa/CoreFoundation app and some other application.