Amen. Shout it from the rooftops!
This is the way.
Disregard ISO8601. Acquire RFC3339. You can leave off the T if you want to, or replace Z with
+00:00.with ISO 8601:
Sure, how about 2018-W06-1? Or 2018-036?
ISO 8601 contains way too many obscure formats. RFC 3339 is pretty much a subset and defines only sensible ones. It also allows 2018-02-05 08:02:43-00:00 (no T and explicitly specifying no timezone)
Acquiring the document (legally) to ensure compliance for ISO 8601 is relatively expensive for a single person (~$200 USD), while RFC 3339 is accessible for free.
I just don’t like to be forced to include the damn year everytime, and if you cut the year from ISO 8601 you get the american MM-DD order, which everybody hates.
I like DD/MM/YYYY. 🤷🏻♂️
If it’s just in casual conversation or emails DD/MM/YYYY is fine, but if you’re naming documents or something in a professional setting, you should really always include the year anyway.
Sounds like something a terrorist would say.
I’m working in an international company with colleagues around the world. To avoid confusion, I switched to using this format:
27-FEB-2013
I deal with a lot of old records and boy I really prefer iso when you have to look at a lot of dates and things are in all different years, it’s helpful. Have you tried ISO? I also do a lot of international work and haven’t heard complaints about it being confusing.
As a Hungarian, I approve.
As an American, I can’t get people in my team to standardize their email signatures with correct spelling.
RFC-3336
I figured there were problems with existing calendars, so I created a new one to supersede all others. That reminds me, though: I need to declare the “official” format for the calendar, to avoid all this nonsense.
I see a window of opportunity, here. Normally, there’s no chance for any calendar revision to succeed in adoption; however, I think if I use the right words with the President, I could get it pushed into adoption by fiat. Y’all had best start learning my new calendar to get ahead of everyone else.
Note for the humorously disadvantaged: the Saturnalia Calendar is a mechanism through which I’m playing with a new (to me) programming language. I am under no disillusion that anyone else will see the obvious advantages and clear superiority of the Saturnalia Calendar, much less adopt it. And no comments from the peanut gallery about the name! What, did you expect me to actually spend time thinking of a catchy name when a perfectly good, mostly unused one already existed?
Why does nobody mention the Discordian calendar? 5 days per week, 73 days per month, 5 months to a year (Chaos, Discord, Confusion, Bureaucracy and the Aftermath). On leap years, it adds one additional day (St. Tib’s day) with a name but no numerical date.
I’m a pope, but then, we’re all popes.
My problem with Discordianism is that it’s all 5s, when 6 is clearly superior, and 12 trumps them all.
Hail Eris.
I’m partial to the IFC.
That’s where I started. I wanted a little project to try V on, and had come across the IFC, so I wrote a thing. While I was doing that, I got to thinking about the deficiencies and inherited complexities in IFC, and thought up Saturnalia.
If you pop up to my profile in Sourcehut, you’ll find a similar program - just a lot longer and more complex, for IFC.
I don’t know if they makes me a genius, but yes. Yes it does.
I’m more into the FRC.
If it isn’t carved into a sheet of limestone using the Mayan character set, I don’t want to read about it.
Hey, I quite like this! You’re the first person I’ve found that’s thought of fixing the calendar by adopting six-day weeks. I have a very similar personal version, with two main differences:
- there’s a leap week instead of a leap day, that way weekdays are always the same without having to skip any and every year has a whole number of weeks (either 61 most years [roughly 7 out of every 8] or 60 on short years [roughly 1 out of every 8])
- December includes this leap week and it’s either 30 or 36 days long, depending on the year. I put it at the end of December for the same logic that you put Saturnalia at the end of the year, to not mess with cardinal dates and so that the Xth day of the year is always the same date
I also came to the same conclusion about workweeks. With two-day weekends, the Gregorian calendar has 71 % of workdays but the new calendar only has 67 %. On a thirty-day month this means 20 workdays instead of 21,5
How does that work, with the leap week? Doesn’t the year drift out of alignment with the solar cycle?
Only in eight year chunks. By year seven there is more unalignment than there was in year one, but it goes back to normal on year eight. Same thing as with leap days, just a slightly bigger scale.
In fact, with current rules, [the shift in the regular Gregorian calendar becomes quite big when considering 100-year and 400-year cycles](File:Gregoriancalendarleap_solstice.svg). In theory, a leap week calendar with new and updated rules could have a very comparable if not a smaller average deviation from the true solar date, though I haven’t ran the precise calculations
Ok, so, first, let me say that while I’m enthusiastic about the concept, I understand it’s entirely theoretical. We can’t even get US civilians to adopt metric, FFS. Just a caveat, lest anyone wander by and overhear us.
That said, I did spend some cycles trying to see it it would be possibly to line up a lunar and solar calendar, and it’s not. And it isn’t nearly as important as it used to be. It would still have been nice.
So if you do run calculations, I’d like to see them.
Here they are! Orange represents my Leapweek calendar and blue is Gregorian. The Y-axis is deviation from the tropical year and the X-axis is the year number. It’s a 19200-year cycle to allow for both Gregorian and Leapweek to do entire iterations of their 400-year and 768-year cycles, respectively.
The Gregorian rules are, as you already know: if a year is divisible by 4, it is a leap year; unless it is divisible by 100, when it is a common year; unless it is also divisible by 400, in which case it is actually a leap year.
My Leapweek rules are: years divisible by 8, are leap (short, with 360 days instead of the usual 366) years, as are years divisible by 768 (after subtracting 4 so as not to clash with years divisible by 8). Just two rules as opposed to Gregorian’s three, but they result in almost perfect correction: it takes 625 000 years to fall out of sync by 1 day, as opposed to Gregorian’s 3 216 years for the same amount)
The catch is that Leapweek falls out of sync by up to 5½ days either way in between 768-year cycles, and up to 2½ days either way in between 8-year cycles. But they average out.
About the lunisolar I’m afraid to say that I ran into the same issue. Lunations are a very inconvenient duration to try and fit into neat solar days and months.
I wish it weren’t as theoretical, because I really like this calendar, but yea. It’s one of those things that will be impossible to change even though there’s arguably better options. It’s too arbitrary yet too essential and it goes in the same box as the metric second/minute/hour, the dozenal system and the Holocene calendar.
Here’s a challenge though: try and devise a Martian calendar! That one is not standardised yet. I had good fun trying to match the Martian sol and year to metric units of time and maybe giving some serious use to the kilosecond, megasecond and gigasecond
As an extra, here’s a 1000-year version of the graph at the start of the reply, with the current year 12 025 of the Holocene calendar :^) in the middle
This is fantastic. I’m going to have to spend more time with it.
Since we’re discussing timescales over which there’s a not insignificant chance something radical will happen to society, there’s also the fact that the day is getting longer by 2ms every hundred years. If you’re scheduling out 625,000 years, that’s 12-some seconds by the end, compounded - 6 extra seconds every day by the 312,000th year, etc.
5/1/2025. I’ll die on this hill.
I’ll call the coroner.
m/d/y, so wrong by default
5/1/5 ?
The 5th January 2025, correct.
Oh please. What’s next? A twelve hour time system with am and pm? Measuring distances in thumbs and other body parts?
Worse: measuring temperatures based on what one guy felt was the coldest it could get in the winter and the hottest his fever would reach.
Don’t be ridiculous, that’s just insane.
To be fair, “thumb” was only a unit in determinating what stick we could beat our wives with.
I’ll see you in hell.
Imagine a database, or even a folder with multiple years in it. “Payroll_05-01-2025”. Now all your files are sorted by month. You would have to scroll through “Payroll_05-08-1988”… etc forever before you reach 2025. And when you do, all of 2025 isn’t together. ISO 8601 solves these issues automatically. It’s time to adapt to a better system…
Fifth January 2025?
My goodness, some of the comments in here must come from people who thought that those writing the standard were morons who did no research.
I don’t think they’re morons…just slaves to convention and compatibility. Not many ways to get away from that and justify it.
I agree with the ISO approach, but unfortunately without mainstream adoption in a majority of countries it’s just another standard.
Working for a global clinical research company, DD-Mmm-YYYY is the easiest for everyone to understand and be on the same page. It’s bad enough identifying which date you’re capturing in metadata without also trying to juggle multiple date formats.
In the last company I work for, the department was created from zero, and my boss just let me take all the technical decisions so from the begging everything was wrote in ISO-8601. When I left it was just the way it was, if you try to use any other date format anywhere something is going to give you an error.
2013-02-27 is a weird way of writing 1361923200
I am a big fan of iso 8601, I just wish it was possible to write more dates than February 27th, 2013 with it
Yeh but for that one day though, everything just works so well.
Harhar
