• LCrawford (unregistered)

    | I always believed that if there was one common thing across all systems and technologies, it was 1970-01-01, the Epoch, the magic date!

    Then there's the Frist of January, 1980 which was the MSDOS epic in the operating system date. (I recently had to dig into this, just like Heidi).

  • S (unregistered)

    On VAX/VMS, the epoch is 17 November 1858 (base of Smithsonian Astronomical Calendar)

  • Francois Botha (unregistered)

    Excel actually has 2 dates systems, the other being the 1904-based system. https://support.microsoft.com/en-za/help/214330/differences-between-the-1900-and-the-1904-date-system-in-excel . When parsing an Excel file, one has to check the properties of a the workbook first before assuming what the internal values (number of days since date x) mean.

  • WTFGuy (unregistered)

    I know it's traditional to transpose something in the first couple of comments trying to be cute. But this time Remy decided to get cute in the references.

    I'm sure the justifiably famous Joel Splosky (sic) won't mind! Unless maybe he's got an explosive temper. I've never met the man and can't say.

    Oh yeah ... almost forgot: ... Frist!

  • David Green (unregistered)

    As soon as I saw that number, I knew it had to be a spreadsheet date. I've seen too many spreadsheets where a date column was reformatted and a similar number was displayed in the column. Ugh.

  • David Green (unregistered)

    As soon as I saw that number, I knew it had to be a spreadsheet date. I've seen too many spreadsheets where a date column was reformatted and a similar number was displayed in the column. Ugh.

  • Zach (unregistered)

    To be honest, that's usually the case in most WTF's and now that you hear the explanation it isn't all that crazy. The detailed explanation

  • Lothar (unregistered)

    In case Tomislav sees a six digit number next like 100195 and it clearly shouldn't be Oct 01 95, you might have JD Edwards internal date format values in your XML as well. That particular value represents 13 Jul 2000, 200194 would be 13 Jul 2100 and 300194 would be 13 Jul 2200.

  • Raj (unregistered)

    XML was early 2000. JSON early 2010. Now we're in the YAML era, and already transitioning to TOML. Can't wait to see the next level of this accelerating cycle of doom. I bet real soon we'll end up back with EDI-like formats.

  • Brian Boorman (google)

    What's with the headline though? IIRC, the flux capacitor was behind Marty between the 2 seats. The Date/Time setting was on the electronics panel mounted above the dashboard.

  • (nodebb)

    We used to use that 1899 date when we wanted SQL Server to only show a time.

  • (nodebb)

    The Pascal/Delphi "0" date/time is also 30 December 1899. Now you know.

  • Little Bobby Tables (unregistered)

    I can identify with that last line.

    In my last position, every so often I used to find myself doing some tedious manual amendment of stuff. We all had to do it sometime or other, and so the lot fell to me. Blow this, thought I, life's too short. So I threw a few lines of code at it and built a little tool to do the tedium. More than once this was picked up on by one colleague or other who saw how quickly I burned my way through the task, and the quick, dirty hack became a de rigueur mainstream maintenance tool, and guess whose job it was to keep them running?

  • badwiring (unregistered)

    The big B2B company where I worked in that decade launched an API sort of thing in 2005. It was called "XML." That's it. XML. Because we had XML. It's some evil XML, too. Users have to write code to construct all sorts of weird elements, and half of it was thrown in to make specific customers happy. 3rd party vendors began aggregating it along with similar APIs from our competitors. The result is that over a decade later, "XML" can never die. Every time they make major updates to any platform or add new services they have to figure out how to keep XML working.

  • Pierre Lebeaupin (unregistered)

    I interpret Tomislav's surprise relative to 1970 as a sign that Unix has won, since its norms are now so ubiquitous that people don't realize they're actually Unix-ish. Speaking of which, the Mac, as Francois alluded to, picked right from the start (1984) the elegant solution of choosing a date span of 136 years and a few weeks (duration mandated by the use of an unsigned 32-bit seconds counter) where January 29th happens exactly every 4 years, from January 1st, 1904 to February 6th, 2040 at 6 AM or so.

  • Thomas (unregistered) in reply to Raj

    As someone who has recently (e.g. I have edited the exporter today recently) had to implement a brand new exporter for an EDI format that stopped being updated 20 years ago.

    Please No. Please make it stop!

    List of formats I have to deal with at work: EDI, XML, JSON, CSV, TSV, .txt ( | delimiter), Excel (for db synchronization..., Export), PDF (Export, Import).

  • Hasseman (unregistered)

    Mind you. XML is just a specific case of SGML ...

  • iWantToKeepAnon (unregistered) in reply to WTFGuy

    https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/

  • RG (unregistered) in reply to Raj

    I work with EDI-files everyday. While much might be told about EDI-files, this is an issue I never had.

  • Llarry Amrose (unregistered)

    MUMPS/M/Cache counts the number of seconds since Dec. 31, 1840. When it was first defined, it had to handle medical records, and, at the time, the oldest date in the dataset was someone born in 1841.

  • (nodebb)

    Best (i.e. worst) date compression ever, from a former colleague: 2-decimal-digit year, one hex-digit month, 2-decimal digit day. Thus 18A04 was 2018/Oct/4

  • Decius (unregistered)

    With so many sequences of bits representing dates, it's amazing that there aren't more collisions between encoding methods that purport to save bits.

  • Dave (unregistered)

    In case anyone's wondering if the different dates in Jan/Feb 1900 were ever a problem in the real world, the answer is yes. Deal with pensions, life insurance, that kind of thing, and many of the people involved are old enough to have been born around that time.

    Even to this day you still find people old enough in the data sets, because (for example) with pensions there are things called 'survivor benefits' which are paid to a surviving partner (usually) of a deceased pensioner;while the people born in 1900 are very likely to be dead by now, their partners may have been at least a couple of decades younger. US veterans' pensions provide an illustration of this, because the US government is (or was in 2016, anyway) still paying a pension to one child of a US Civil War veteran (who married a woman 50 years younger), and if one looks at the First World War, where every US vet ought to have been born before 1900, there are over a thousand surviving spouses.

    That said, I don't remember a case where the day of the DOB actually mattered. But I have had to check for 'matching DOB, or, matching DOB minus one day if it's in Jan/Feb 1900'.

  • Klimax (unregistered)

    And there is also Win32 epoch: https://blogs.msdn.microsoft.com/oldnewthing/20090306-00/?p=18913/

    IMO one of the sanest choices.

  • Anonymous Robot (unregistered)

    Every time I get discouraged by this job, I console myself - 'At least I'll be dead in 2038 and won't see that one blow up'. You kids out there, I pity your future.

  • WTFGuy (unregistered) in reply to iWantToKeepAnon

    Your point being? That's the same article Remy linked to in his reference section at the bottom of his article.

  • WTFGuy (unregistered) in reply to Pierre Lebeaupin

    I'd suggest it's more a matter that there are Unix-world people who know little of the larger computing universe, Windows-world people who know little of the larger computing universe, and traditional mainframe-world people who know little of the larger computing universe. And some slowly growing percentage who have lived professionally in more than one world.

    The geographical distribution isn't consistent either; Unix-only devs may heavily outnumber Windows-only devs in, e.g. Russia, whereas the stats are more balanced in e.g. Western Europe.

    Although with both MS Windows and IBM z/OS gaining ever more Unix API- & feature- compatibility at ever deeper layers of the OS Unix may eventually become the de facto norm as you predict. Just wait another 50 years.

  • WTFGuy (unregistered) in reply to WTFGuy

    Replying to myself and cutting iWantToKeepAnon some slack.

    I see Remy has corrected his typo.

    FTR early this morning Joel's name was written incorrectly as "Splosky". And that's what I was joking about in my first post (#4 in the thread). Remy has since changed it to the correct "Spolsky." Anyone seeing my comment but not having seen the original typo would be justifiably baffled.

  • Jw (unregistered)

    Matlab, when converting datetime objects to datenum floats, uses as epoch 1 Jan. 0000 (for datenum == 1). Why they use 1-based indexing everywhere except for their epoch year, I don't know...

  • gidds (unregistered)

    Even the Unix epoch isn't totally problem-free. For example, did you know that on 1970-01-01, the UK was on summer time?? Yes, that one caused me some head-scratching...

  • (nodebb)

    SPSS date variables are stored internally as the number of seconds since 14 Oct 1582 00:00:00.

    Why did IBM choose such a weird start epoch? 14 Oct 1582 happens to be the first day of the (then) new Gregorian calendar, instituted by Pope Gregory II. The day before was 5 Oct 1582 - accounting for those missing days makes for some horrible mathematics, so IBM just avoided it.

    The missing days were to make up for all the mistaken extra days they’d added in previous centuries for Leap Years that shouldn’t have been (those years that could divide by 100, but not 400).

  • Chris (unregistered) in reply to Brian Boorman

    "IIRC, the flux capacitor was behind Marty between the 2 seats. The Date/Time setting was on the electronics panel mounted above the dashboard."

    How do you adjust the date/time on your computer? By interacting with the monitor on your desk, or by somehow messing with the box that houses the hardware? (Making assumptions about your computer setup, I know)

  • Dates are not the only fruit (unregistered)

    SQL Server? I never paid any attention, but SQL server dates were off-by-one from VB dates around date zero, which suggests that SQL server did /not/ implement this feature. And no reason to expect it would: it started as a third-party product without any requirement for excel/lotus compatibility.

  • (nodebb)

    Like David Green, I saw 39002 and immediately thought "Excel date." Possibly I use Excel too much...

  • Kdu Bonalume (unregistered)

    "For me, the key take away is how small choices made ages ago, decisions which made sense at the time, keep cropping up." Reminds me of the story of the railroad gauge.

    The US standard railroad gauge (distance between the rails) is 4 feet, 8.5 inches. That’s an exceedingly odd number.

    Why was that gauge used? Because that’s the way they built them in England, and English expatriates built the US Railroads.

    Why did the English build them like that? Because the first rail lines were built by the same people who built the pre-railroad tramways, and that’s the gauge they used.

    Why did “they” use that gauge then? Because the people who built the tramways used the same jigs and tools that they used for building wagons, which used that wheel spacing.

    Okay! Why did the wagons have that particular odd wheel spacing? Well, if they tried to use any other spacing, the wagon wheels would break on some of the old, long distance roads in England, because that’s the spacing of the wheel ruts.

    So who built those old rutted roads? Imperial Rome built the first long distance roads in Europe (and England) for their legions. The roads have been used ever since.

    And the ruts in the roads? Roman war chariots formed the initial ruts, which everyone else had to match for fear of destroying their wagon wheels.

    Now, when you see a Space Shuttle on its launch pad, there are two big booster rockets attached to the sides of the main tank. These are solid rocket boosters, or SRBs. They are made by Thiokol at their factory in Utah. The engineers who designed it would have preferred to make them a bit fatter, but the SRBs had to be shipped by train from the factory to the launch site. The railroad line from the factory happens to run through a tunnel in the mountains. The SRBs had to fit through that tunnel. The tunnel is slightly wider than the railroad track, and the railroad track, as you now know, is about as wide as two horses' behinds.

  • Sipho (unregistered)

    We have name for such "fixes" here. Everyone talks about workarounds, but we all secretly know and now call them by there name: stayarounds

  • Little Bobby Tables (unregistered) in reply to cellocgw

    Two digits for the day of the month? How wasteful! 5 bits is perfectly adequate!

  • (nodebb)

    Until I looked at the list of notable Epoch dates and Wikipedia, I did not know that my birthday did not exist.

    https://en.m.wikipedia.org/wiki/Epoch_(reference_date)#Notable_epoch_dates_in_computing

    Addendum 2019-02-06 08:50: Notable epoch dates in computing

    Addendum 2019-02-06 08:50: Notable epoch dates in computing

    Addendum 2019-02-06 08:50: Notable epoch dates in computing

  • I'm not a robot (unregistered) in reply to gidds
    Even the Unix epoch isn't totally problem-free. For example, did you know that on 1970-01-01, the UK was on summer time??
    ... OK? I hate to think what kind of code you're writing that has "the UK must have been using standard time at the epoch" as an assumption, that would cause that to be a "problem".
  • Gnasher729 (unregistered) in reply to Anonymous Robot

    The 2038 problem (2^31 seconds after Jan 1st 1970) isn’t really that bad. All you need to do is to change it to 64 bit integer (or double precision floating point like macOS or iOS do.

  • Brian Boorman (google) in reply to Kdu Bonalume

    False.

    https://www.snopes.com/fact-check/horses-pass/

  • nat42 (unregistered)

    Visual Foxpro uses something like the days after September 14, 1753 as its epoc date; the date England adopted the Gregorian calendar. The day prior (which isn't handled correctly) was on the old calendar and was Wednesday 2 September 1752 that year (that is a bunch of days in September were skipped)

  • WTFGuy (unregistered) in reply to I'm not a robot

    If you need to correctly manage time zones, you need to know which time zones were in effect at every possible where on every possible when. The idea that even your epoch date, the origin of all your time reconing, is actually subject to a special case is alarming and unexpected.

    The epoch being in a weird DST situation is kind of like discovering the Prime Meridian runs almost, but not quite, due north & south and has some bends in it.

  • eric bloedow (unregistered)

    this reminded me of a book, "the hacker crackdown". in the epilogue, the author interviews Michel Kapor. he says he used to work for Visicalc, BUT "they made the mistake of bringing in professional management. that drove them into the ground." Michel quit, and FOUNDED Lotus...which a few years later, BOUGHT Visicalc! "kind of like Bell buying western union?" "yep, exactly!"

  • I'm not a robot (unregistered) in reply to WTFGuy
    If you need to correctly manage time zones, you need to know which time zones were in effect at every possible where on every possible when.
    That has nothing to do with the choice of epoch.
    The idea that even your epoch date, the origin of all your time reconing, is actually subject to a special case is alarming and unexpected.
    So in other words there's no logical reason why it would be a problem, you're just superstitious and fearful.
    The epoch being in a weird DST situation is kind of like discovering the Prime Meridian runs almost, but not quite, due north & south and has some bends in it.
    The only thing "weird" about the situation described is that the UK was using something described as "summer" time when it wasn't actually summer in the UK. Like I said, if your code cares about that somehow (and in such a way that it's only a problem when it happens at the epoch, but would be fine at any other time), then you are TRWTF.
  • Moi Oci (unregistered)

    This feature/bug figures prominently in Joel's story about his BillG review: https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/.

Leave a comment on “Set the Flux Capacitor for 12/30/1899”

Log In or post as a guest

Replying to comment #503118:

« Return to Article