Talk:1467: Email

The strftime format used is probably %Y-%M-%D %h:%m:%s, which visibly looks as if it will yield a date and time, yet doesn't. A more correct format would have been %Y-%m-%d %H:%M:%S. ‎197.234.242.236 (talk) (please sign your comments with ~~~~)

There's a strange thing with the date string : why 30 ? The timestamp shows 31 as a day in month and 5:54 which doesn't match 30... 54 looks like the week in year but matches with the minutes. Goufalite (talk) 09:57, 31 December 2014 (UTC)

The explanation now mentions that Randall goofed - the string he typed in states "30" when it should be "31". KieferSkunk (talk) 21:06, 1 January 2015 (UTC)

What on earth does 'Created for a live studio audience mean'?! 141.101.106.143 10:03, 31 December 2014 (UTC)

"Unix" is misleading. Sure, unix "date" command is using this kind of formating, but it's also in C standard (specifically, C89 and C99) and available in most other programming languages standard libraries (including perl, php, python, ruby), often as ONLY way to format date without fetching every component separately. -- Hkmaly (talk) 13:15, 31 December 2014 (UTC)

The C standard is largely based on the earlier Unix standard, so referring to "Unix" time is in fact correct and will make more sense to a larger set of readers (most computer users are at least vaguely aware of Unix and how it predates virtually all modern OSes, while less of them understand programming languages, let alone the various standards that exist in them). KieferSkunk (talk) 21:06, 1 January 2015 (UTC)

I'm fairly confident that I used the term "email" before 1993, because of what I was doing before that date. But I also couldn't give any definitive sources. And I mean the name, not just the general Port 25 thing or its predecessors. But meh, no real proof unless I get lucky digging around in 5.25" floppies for old backups that I doubt I could read anyway... 141.101.98.191 13:23, 31 December 2014 (UTC)

People were using the term "email" back in the days of modem-based bulletin-board systems (BBSes) and time-sharing services well before those systems were interconnected via the Internet. But back then, those were pretty specialized systems with specialized user groups. The explanation refers to when email became widely accessible to anyone with the ability to connect to the Internet (and coincided with the rise of "free" ISPs - "free" in quotes because most of them placed adware on your computer). 1998 is the year most often cited as the point where the Internet went fully mainstream - before that, it was still primarily a place for computer geeks. KieferSkunk (talk) 21:06, 1 January 2015 (UTC)

Might be worth explaining %D vs %x for other locales. Glen442 (talk) 15:28, 31 December 2014 (UTC)

How does "1420001642" translate into "2014-12-31 at 04:54:02"? Smperron (talk) 16:35, 31 December 2014 (UTC)

The number is literally a count of milliseconds between the Unix "Epoch" (1/1/1970 at 00:00:00). The Unix standard uses a single large number to represent the absolute amount of time that has passed since that time. Calendar algorithms know how to translate that number into a human-readable date/time (remember, the Gregorian calendar and the 12/24-hour clock are really just human-devised methods to tell what day and time it is). There are lots of good whitepapers that describe how these algorithms work. The basic calculation is shown in the Trivia section. KieferSkunk (talk) 21:06, 1 January 2015 (UTC)

Whoops - number of SECONDS since epoch, not milliseconds. Sorry. :) KieferSkunk (talk) 21:25, 1 January 2015 (UTC)

By the way, a handy site for this is http://www.unixtimestamp.com/index.php . KieferSkunk (talk) 21:34, 1 January 2015 (UTC)

the title text gives a date of 30 not 31 which means randell made a mistake!!! refer to http://www.unixtimestamp.com/index.php Needforsuv (talk) 19:03, 31 December 2014 (UTC)

I have added that Randall made a mistake with 30 vs 31 and have also made a trivia entry that explains how the unix time stamp string becomes the specific date. Since this is called a unic time stamp it also makes sense to call it a unix time although it is also used by other languages. Kynde (talk) 12:25, 1 January 2015 (UTC)

I don't think he made a mistake. Internal Unix timestamps are always stored UTC and strftime does the necessary calculation in order to present the time in the user's locale. Presuming he was located somewhere at least 5 hours before UTC (e.g. the continental US), 1420001642 would give that output. 108.162.238.192 21:57, 1 January 2015 (UTC)

Good catch - I just realized this as well. I think the output of the %D token was actually translated to his local time zone, so it's CORRECT in that's what the formatter told him, further highlighting just how confusing this all can be. KieferSkunk (talk) 22:15, 1 January 2015 (UTC)

I've gone ahead and rewritten that part of the explanation. I really couldn't imagine Randall making that big of a mistake, especially since he's such a stickler for details like that. This makes a lot more sense now. KieferSkunk (talk) 22:25, 1 January 2015 (UTC)

In the trivia section, dividing the timestamp by 365.25 to get the number of calendar years ellapsed (not solar years) would only work if 25% of years since 1970 are leap years, which was true in 2014, but not in 2015, 2016... 108.162.229.129 21:35, 1 January 2015 (UTC)

Given that the calculation is only getting the integer number of years, this still works. In 2015, the division will still yield "45" plus a fractional amount that is discarded for that part of the calculation. KieferSkunk (talk) 21:52, 1 January 2015 (UTC)

Actually, to explain further, the "number of days" calculation allows for a 365th day (that would be December 31, given that February would have 29 days instead of 28). This is, in fact, the correct way to calculate the number of calendar years. (You're right that it doesn't correspond to SOLAR years, but we don't use a strictly solar calendar, and there are in fact errors in the Unix standard between those two measurements.) KieferSkunk (talk) 22:29, 1 January 2015 (UTC)

If you drop the rest of the division you're right most of the time. Although, I maintain there are counter examples, like, the 31 december of 1970 at 11pm : since 1970 was a leap year, at that time, about 365.95 days had ellapsed since unix epoch, and the integer division would result in year +1, while it's still year 0. The problem becomes more serious if you use the rest of the division to continue calculation, which will provide an error in 75% of cases. 108.162.229.129 11:07, 2 January 2015 (UTC)

Huh? 1970 wasn't a leap year - the next leap year from there was 1972. KieferSkunk (talk) 20:12, 2 January 2015 (UTC)

Ooop, sure, sorry. So the counter example would be 1971, 1st january at 1am, 365.05 days having elapsed, and 365.05 div 365.25 giving year 0 instead of +1. 108.162.229.129 22:12, 6 January 2015 (UTC)

This simplified calculation may work out to get the right integer year, but if you then reconvert that to seconds and subtract it from your timestamp, you will definitely make mistakes. The shown example is correct because the 44 years since 01/01/1970 contain exactly 11 leap days (44*0.25), but if you select a date in 2013, for instance, the calculation will include 10.75 leap days and yield the wrong result. Also, the assumption of a leap year every four years only works until the year 2100 (not a leap year). 162.158.150.10 13:16, 13 November 2017 (UTC)

Also in Trivia, there's a bullet that reads "The 364th day of a non-leap year is December 31[...]", this is only true if January 1 is the 0th day of the year, which is mathematically correct and confusing to non-programming humans. It should read 'The 365th day[...]' or '[...]which translates to the 365th day[...]'. 108.162.241.11 (talk) (please sign your comments with ~~~~)

This is the problem with math: Basic mathematics is zero-based - counting upward from the beginning of anything, you only arrive at 1 when you've reached your first complete unit. You can refer to "the first half-foot", but the measurement would be 0.5 feet, or less than 1. Similarly, while you're at any point before midnight on January 2nd, you're less than 1 day into the year, and the current amount of time having passed since the start of the year is 0.x days. We don't have to be programmers to get this, and considering it's a comic for science, math and computer geeks (primarily), I think we SHOULD expect our audience to get at least SOME of this. KieferSkunk (talk) 02:24, 2 January 2015 (UTC)

That said, I went ahead and changed it to "365th day", given the description of the calculation already mentions that 364 days have elapsed since the start of the year. That should bridge the gap. (I made that distinction a little clearer as well.) KieferSkunk (talk) 02:30, 2 January 2015 (UTC)

"via fax, a technology that predates SMTP by more than a decade." The first fax was in 1861, so pre-dates SMTP by a century 141.101.98.163 (talk) (please sign your comments with ~~~~)

Really? They had facsimile modems back in 1861? Source, please. KieferSkunk (talk) 20:11, 20 January 2015 (UTC)

Alexander Bain received patent #9745 for a fax process in 1843. The first practical fax machines appeared in 1881 (which is probably the year the OP meant), using telegraph technology. 108.162.213.29 (talk) (please sign your comments with ~~~~)

Why would he even give the year that is about to start (the one he has the resolution for) as a timestamp, let alone one, that is showing not only the year, but also days, hours, etc.? --Lupo (talk) 08:05, 11 July 2019 (UTC)