A video uploaded two years ago on 10/14/2021 would still tell you it was one year old if it were uploaded later in the day.
Then it doesn’t matter if you write it
November 12 2012
2012 November 12
12 November 2012
2012 12 November
Etc.
How would 2012 ноябрь 12 feel to you?
2021-11-21 15:10:35
See how much easier that is?
irb> puts “2021-11-21\r\t15:10:35”
2021-11-21
15:10:35Not that avoiding such names solves the problem, it just makes the RCE vulnerability more latent.
But I don't mean to pick a Star Wars / Star Trek fight: I'm bistellar, I love both of them!
I had to fix so many of these in various databases and frontends, lol
A website/app shouldn't have to find your timezone. It should use whatever one you've set. If you've set your timezone to one you didn't want, I'm not sure what you'd expect other software is meant to do about that. Fix your config.
Even if the user set it in one time zone, if we store it without a proper offset (and preferably a locale), we cannot properly account for the user traveling to another place, daylight savings time, government time adjustments, leap time, etc. These complexities compound off each other and make proper scheduling and debugging time issues really, REALLY hard later on.
In the twenty years or so that I've been doing web dev, datetime is probably the single biggest gotcha I've seen developers (including myself) stumble into. Part of this is because the standard JS datetime handling is atrocious compared to any other language I've worked in. It doesn't really natively handle time zones well, and well carelessly cast them back and forth if you're not careful.
Moment and Luxon can help with this, lighter libs like date-fns can too with the right extensions, but out of the box JS is going to fuck it up. I promise. Another choice is to just use milliseconds to store everything, and convert that to the user's timezone only at the time of display. Every timestamp is stored as an epoch, and every user has their time zone (not just offset, because of daylight savings) recorded with their profile. Doing those two simple things can avoid most of the landmines.
And javascript natively converts epoch time to whatever timezone the client has set. If your user-agent (aka browser) is working on New York time, but you're in Tokyo, well, I'm not sure who else you have to blame but yourself if it shows you New York time when you didn't want that.
I think I'd be ok with this. I love the KDE fuzzy clock that says it's "about lunchtime", much more human than the examples people are decrying here.
In the end though we just used checksums, but over the wire the larger files take too long. This comment has given me an idea!
So for example check modified, inode number against the previous version. If they are all a match consider skipping the checksum. This way you can skip almost all checksums on an incremental transfer. You can have false-negatives but this can often be mitigated by occasionally doing a full rescan or similar.
To be honest, I didn't even try this because the destination machine is Windows, I didnt think inode number had an equivalent in windows, but after googling, there might be a way.
Another great suggestion.
As for the full checksum, I went with a chunk size of the first and the last of the file, (the changes are very small, property based) but I don't think its as reliable.
1 - I rarely eat a meal in the middle of my day. In fact I usually only eat once, so is that one meal lunch? or breakfast? or dinner? or what ??
2 - My day not only isn't the same as yours, it isn't even the same from day to day, so even if I agreed to call my one meal lunch instead of dinner, it does not come at the same time as yours does, and does not even come at the same time from day to day, and does not even come at the same time relative to when I am awake let alone the absoluet time.
It's inconsiderate to think this is reasonable for everyone else because it's reasonable for you. It's like how kids and the untravelled and otherwise ignorant presume everyone else's life is exactly the same as theirs.
I could translate of course, because of course I know what it means for probably the majority of everyone else, but why should I have to do that? This whole topic is about convenience and meaning, and this would be inconvenient and of only arbitrary meaning to me. It would be like calling it "triangle time" sure, I could just know that that means around noon. Why should my interface require me to translate from markers that are meaningful to someone else's life but not to mine?
A worse example just to show what's so wrong would be like calling sunday "church day". Or sunday afternoon "right after church". That would be not only inconsiderate but downright offensive. For a lot of people that would be perfectly fine and some of them would even fail to see why that should be a problem for anyone.
And the offense isn't just mentioning a religion, it's the assumption, the turning anyone else into the exception, when they are not an exception, they are equal.
FTFY
When such relative dates are in a list it's generally tolerable. The failure to update is far more irritating, and limiting to "yesterday" does not fix that.
I don't want to do date math in my head! Just give me the precise timestamp!
Don't throw away information with nonsense like "1 year ago" when as the parent post says, that could mean anything in a huge range of days.
Just show the actual timestamp!
I see proper timestamps in Finder in Date Modified column.
The current generation of UI / UX people come usually from non tech backgrounds and are people very keen on... Making things pretty. They seem to know very little, however, about usability and other principles that we, developers, used to care about.
For most people, exact time doesn’t even really matter — it’s about estimating a broad chronological context for the most part. I’d just wish the UI would have a universal and easily accessible way to disclose the exact time when I actually need it.
But that is throwing out the baby with the bath water. The existence of multiple locally used data formats is no reason replace information with this oversimplified nonsense. Browser can and used to provide the locale with every request. That is enough information to format a data such that it is readable to the user.
Citing RFC 3339 is usually a better idea, since in addition to be readable for free, it is limited to the date formats you are thinking about. My 2 cents on your preferred citation, keep preaching though!
https://datatracker.ietf.org/doc/html/rfc3339
With apologies for the delayed response, I got here from the weekly hackernewsletter.
For better or worse (worse, IMHO), this is how YouTube search works. It takes at least two HTTP requests to get the precise dates. One to retreieve the SERP. Another to retrieve the JSON for each videoID. The JSON contains the upload date, etc.
IMO this sort of inefficient design pattern is faciltated by web developers who rely on Javascript, which is seemingly all of them. Webpages become shells for advertising and Javascript is used to fetch non-advertising, i.e., data. Google wants users to make clicks and track them, i.e., collect behavioural data. Thus it makes sense that a user would be forced to "open" a video to see its actual upload date.
The suite of tiny custom utilties I wrote in C can search YT and retrieve all YT videos, this can be upwards of 900 results. The output is CSV, SQL or simple HTML, including upload date and other data I find useful. This is done using only two TCP connections. No browser is needed. The simple HTML is just a page that looks like CSV, with a hyperlink to the video file. It's "YT redesigned" to look like I want it to look. I do the web development before opening the page in a browser.
The custom "downloader" I wrote is smaller, simpler and faster than yt-dlp. No Python required. But most times I don't download. I just use the simple HTML that looks like CSV. IMHO, this is much better than Google's privacy-invasive page laden with Javascript. I can see the precise dates and other useful data. I can sort by vaious columns. And I can exclude garbage videos that Google ("the algorithm") inserts into results, videos that have nothing to do with the search query string I submitted.
You don't need malice to explain that --- just A/B testing. Making information, that a user wants or needs, less accessible increases engagement, since the user is clearly clicking more.
So if I see two videos that were both uploaded "a year ago", it's impossible to know which is more recent without actually opening the videos, going to the description, and looking at the date.