7 ms·
Date is out, Temporal is in
- xeckr 9mo agoI suspect that the arrival of ChatGPT caused traffic to the MDN Date API documentation to go down by at least half.
- qsort 9mo agoTo be fair it's exactly the type of stuff I'd be glad if I never have to think about again.
- ivanjermakov 9mo agoGo down by half of user traffic, go up 10x of crawler traffic.
- themafia 9mo agoThe Date API is fine and relatively normalized. Once you understand it it's very easy to work with. It's biggest problem is that it simply does not support timezones, which is the main reason to use Temporal.
- winstonp 9mo agoyep. i had a hell of a time building a scheduling system for a business that worked across timezones with the date API
- LtdJorge 9mo agoThe Date API is horrible
- themafia 9mo agoYea, that's understood to be the opinion, blandly repeating it adds little to the discussion. It's simple. In it's simplicity it left many features on the floor. I just can't connect with the idea that someone would need to constantly be on MDN in order to work with it. It's not so horrible that it defies logic.
- acdha 9mo agoIt’s not simple, though. Simple would be something like an object wrapping YYYY-MM-DD, like a COBOL programmer in the 1950s would’ve used. Instead, people have made thousands of variations of bugs around the complexity even basic usage forces you to internalize like the month number being zero-based while the year is 1900-based but the day of the month is 1-based following standard usage.
- devilsdata 9mo agoIt's not simple, it has hidden pitfalls and footguns. Using it is the fastest way to blood on the floor (to quote a senior developer I worked with).
- deleted 9mo ago[deleted]
- thoughtpalette 9mo agoBuilt a scheduler with pretty much all my moment/moment-tz questions answered through ChatGPT. One of the things it excels at, crawling long lived API documentation, answers, etc.
- crabl 9mo agowe've been using this Temporal polyfill and it's been awesome so far: https://github.com/js-temporal/temporal-polyfill https://github.com/js-temporal/temporal-polyfill
- whizzter 9mo agoHow is it compared to moment and especially luxon?
- kristo 9mo agoIt’s a web standard api and very small weight. Highly recommend.
- socalgal2 9mo agoDidn't moment basically say in so many words, use Temporal?
- WorldMaker 9mo agoMoment said many years ago "use Luxon" [1]. Luxon is not yet at the "use Temporal" stage [2]. [1] https://momentjs.com/docs/#/-project-status/ https://momentjs.com/docs/#/-project-status/ [2] https://github.com/moment/luxon/discussions/1742#discussioncomment-14629994 https://github.com/moment/luxon/discussions/1742#discussionc...
- socalgal2 9mo agohttps://momentjs.com/docs/#/-project-status/future/ https://momentjs.com/docs/#/-project-status/future/
- MrJohz 9mo agoIt is a lot more complex than moment, but only because there's a lot of inherent complexity to dates and times that moment just doesn't deal with. So you need to be explicit about whether you're dealing with dates, times, or datetime objects, whether or not the object you're working with has a timezone, etc. Where moment is generally designed to have a convenient API, Temporal is designed to have a correct API.
- LoganDark 9mo agoIs Temporal even in though? Last I checked (last year or so), I had to use some bleeding edge version of Firefox to get it, and absolutely nothing else had it. I do agree though it's lovely, and I'd love to see native support for it.
- noelwelsh 9mo agoNope. Only Firefox and Chrome have it, in their latest versions. No Safari or Edge support yet. So this article is a bit premature (unless you use the polyfill.)
- lobo_tuerto 9mo agoYou can always check in "Can I use _?": https://caniuse.com/temporal https://caniuse.com/temporal
- halestock 9mo agoIt's fully supported as of version 139[0], so since ~June of last year. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- flenter 9mo agoSeems like the next version(s) of Chrome will have it: https://caniuse.com/temporal https://caniuse.com/temporal
- tensegrist 9mo agotypo: // A numeric string between 32 and 49 is assumed to be in the 2000s: console.log( new Date( "49" ) ); // Result: Date Fri Jan 01 2049 00:00:00 GMT-0500 (Eastern Standard Time) // A numeric string between 33 and 99 is assumed to be in the 1900s: console.log( new Date( "99" ) ); // Result: Date Fri Jan 01 1999 00:00:00 GMT-0500 (Eastern Standard Time) the second interval should start at 50, not 33
- ckocagil 9mo agoLate by a decade or more (JSR310 was released in 2014), but still a good development. I've tried convincing colleagues to use js-joda in the past but they thought they were keeping it simple by sticking to moment.js. They weren't.
- gardnr 9mo agoI remember running into the moment.js issue where my package size doubled by adding a date library: https://github.com/moment/moment/issues/3376 https://github.com/moment/moment/issues/3376
- zvqcMMV6Zcr 9mo agoI am not sure if I like mixing value and formatting in single object. On other hand anything will be an improvement compared to that terrible old API.
- happytoexplain 9mo agoTemporal objects do not store formatting information. Unless you mean e.g. dropping the time, using a different time zone, etc - but those aren't formatting changes, they logically change the semantics of the data. Just like `myInt += 1` is not changing the "formatting" of `myInt`. Remember: Date and Temporal objects are logically different things. A Date represents an absolute point in time (a timestamp), while a Temporal object represents a human time (calendar date, clock time, time zone). The fact that Dates are used to represent human time for lack of a better structure is the entire problem statement - the hole that all these other APIs like Temporal try to fill in.
- zvqcMMV6Zcr 9mo agoI just groked it before and thought "plain" in `Temporal.PlainDateTime` indicates some specific format instead of just being zoneless. It is actually always using ISO8601 fur build in toString conversions, so I don't really have anything to complain about.
- sublinear 9mo ago> My complaint is about more than parsing or syntax or “developer ergonomics” ... My problem with Date is that using it means deviating from the fundamental nature of time itself. I don't really have a problem with the substance of this blog post. I have a problem with this exaggerated writing style. It means deviating from the fundamental purpose of writing itself! I had to scroll all the way to the end to find the actual point, and it was underwhelming. > Unlike Date, the methods we use to interact with a Temporal object result in new Temporal objects, rather than requiring us to use them in the context of a new instance Bro, just be honest. This entire blog post was totally about developer ergonomics and that's okay. We all hate the way Date works in javascript.
- happytoexplain 9mo agoIt's not an exaggeration - you're used to dramatic phrases that use similar wording ("fundamental nature of time itself"), but in this case it's a regular old literally-true statement. Date is used to represent two things: Timestamps and human times (date, time, tz). But it only actually represents the former. Using it to represent the latter is a hack we simply put up with.
- sfink 9mo agoPedantically, Temporal also deviates from the fundamental nature of time itself. Temporal.Instant? In which accelerating frame of reference? It supports equality, which is a nonsense concept.
- Aardwolf 9mo agoChecking its API, I'm surprised that Temporal.Duration has a constructor with many parameters for years, months, days, ... all the way to nanoseconds, while Temporal.Instant has no way at all to create it given a current year/month/day, only from unix timestamp equivalents (or strings) That seems to be functionality you'd want to have? Or is the intention you convert your numbers to string first and then back to a Temporal.Instant?
- Macha 9mo agoI guess they don’t want people getting confused between local and UTC values for the fields in the constructor (especially as if it took local values it would need to handle DST transitions)
- sheept 9mo agoit's because a year/month/date isn't enough to uniquely identify an instant in time. you can create a Temporal.PlainDate(Time) with those values though, then convert to the other types depending on what you need and it needs (e.g. time zone)
- tshaddox 9mo agoIt's perfectly reasonable to default seconds, minutes, hours, etc. to zero in the Duration constructor. But for Instant, it doesn't make sense to default those to zero unless you specify time zone offset. And indeed, the static method Instant.from does accept an RFC 9557 string, which requires a 2-digit hour and a time zone offset, but can omit minutes and seconds: Temporal.Instant.from("2026-01-12T00+08:00")
- moralestapia 9mo agoNot yet, adoption is kind of poor atm. This is not to detract from the quality of the article which is a top-notch introduction to this new API.
- jdonaldson 9mo ago[flagged]
- DarkNova6 9mo agoWhat’s the superior alternative and in which domains?
- Someone1234 9mo agoExcept Temporal is not, in fact, out. https://caniuse.com/temporal https://caniuse.com/temporal The current global availability of native Temporal is 1.81%. For context, IE11(!) has a higher global usage than Temporal has native support. For my organization, this likely means we're years from being able to use Temporal in production, because getting the polyfills approved is such a hassle. Keep in mind that even as of December last year, Chrome didn't ship with it yet (i.e. support is less than one month old). Safari still does not.
- senfiaj 9mo agoChrome will ship in 144. It's about to release.
- winstonp 9mo agoOnce Chrome does, for many devs, you can simply enforce a version check and say "please use latest Chrome" and be done with it.
- promiseofbeans 9mo agoPlease never do version checks. Test for the existence of the exact features/methods you need instead - this is trivial in JS: if(Temporal) Checking against version numbers helps cement existing browser monopolies, makes it difficult for new browsers to view websites (even if the browser correctly implements every feature), and encourages everyone to spoof version numbers / browser names which leads to them becoming a less and less useful signal. See any browser’s User-Agent string for an example of this
- themafia 9mo agoThankfully temporal-polyfill only depends on temporal-spec. It was pretty easy to get that through.
- deleted 9mo ago[deleted]
- rjrjrjrj 9mo agoGood article, but “Java deprecated their Date way back in 1997” is not exactly true. They deprecated a lot of methods and constructors in JDK1.1 when Calendar was introduced, but the class itself was never deprecated and it was the preferred way to represent a point in time until the “modern” approach was provided in java.time in JDK8 (c2014)
- shellac 9mo agoNot exactly true, but they deprecated absolutely everything that made it a date. It expresses deep regret in the medium of annotations: https://javaalmanac.io/jdk/1.2/api/java/util/Date.html https://javaalmanac.io/jdk/1.2/api/java/util/Date.html (I can't find the 1.1 docs, but they were the same) It's one of my favourite examples of how languages pretty much always get date and time hopelessly wrong initially. Java now has one of the best temporal APIs.
- KwanEsq 9mo agohttps://javaalmanac.io/jdk/1.1/api/java.util.Date.html https://javaalmanac.io/jdk/1.1/api/java.util.Date.html
- shellac 9mo agoCurses, I was close. Also: yikes to the design.
- rjrjrjrj 9mo agoYeah, it effectively became a typed wrapper of a long epoch millis value. Generally treated as immutable by convention in my experience, although of course it technically wasn't as the setters were never removed. It was hopelessly wrong initially, and got even worse when they added the horrible sql Date/Timestamp/etc classes. With java.time though, it is the gold standard as far as I've seen.
- cogman10 9mo agoJava's time and duration representations, heavily based on Joda, should be the standard that every language works towards. It's just about perfect in every way. It makes it easy to do the right thing and it's very pleasant to read.
- artursapek 9mo agobro these ads I can't
- tshaddox 9mo agoThis article lists several of the absurdities of the Date constructor, but only barely touches on the most unforgivable one. The example from the article is: // Unless, of course, you separate the year, month, and date with hyphens. // Then it gets the _day_ wrong. console.log( new Date('2026-01-02') ); // Result: Date Thu Jan 01 2026 19:00:00 GMT-0500 (Eastern Standard Time) In this example, the day is "wrong" because the constructor input is being interpreted as midnight UTC on January 2nd, and at that instantaneous point in time, it is 7pm on January 1st in Eastern Standard Time (which is the author's local time zone). What's actually happening here is a comedy of errors. JavaScript is interpreting that particular string format ("YYYY-MM-DD") as an ISO 8601 date-only form. ISO 8601 specifies that if no time zone designator is provided, the time is assumed to be in local time. The ES5 spec authors intended to match ISO 8601 behavior, but somehow accidentally changed this to 'The value of an absent time zone offset is “Z”' (UTC). Years later, they had realized their mistakes, and attempted to correct it in ES2015. And you can probably predict what happened. When browsers shipped the correct behavior, they got too many reports about websites which were relying on the previous incorrect behavior. So it got completely rolled back, sacrificed to the altar of "web compatibility." For more info, see the "Broken Parser" section towards the bottom of this article: https://maggiepint.com/2017/04/11/fixing-javascript-date-web-compatibility-and-reality/ https://maggiepint.com/2017/04/11/fixing-javascript-date-web...
- teiferer 9mo ago> sacrificed to the altar of "web compatibility." What should they have done instead? Force everybody to detect browser versions and branch based on that, like in the olden days of IE5? (Serious question, maybe I'm overlooking some smart trick.)
- tshaddox 9mo agoI agree with the "don't break the web" design principle, but I sometimes disagree with precisely where TC39 draws the line. There is obviously a cost to breaking old, unchanging websites. But there's also a cost to allowing old, unchanging websites to hold the entire web hostage. Balancing those costs is a subjective matter. As far as I know, TC39 doesn't have any clear guidelines about how many websites or how many users must be affected in order to reject a proposed change to JavaScript behavior. Clearly there are breaking changes that are so insignificant that TC39 should ignore them (imagine a website with some JavaScript that simply iterates over every built-in API and crashes if any of them ever change).
- daveoc64 9mo agoI'm really surprised at how Temporal is only just rolling out in Chrome stable. I would have hoped it'd be ready for wider use by now. https://caniuse.com/temporal https://caniuse.com/temporal
- ZeWaka 9mo agoAll the chromiums are scheduled for this week. Still TP for WebKit.
- promiseofbeans 9mo agoWe’ve been loving using it in our Deno servers since last year. It’s been frustrating that we haven’t been able to upgrade our web client date logic yet, since even though Firefox has supported Temporal for a while, Chrome have really dragged their feet
- nekevss 9mo agoI don't know if that's totally fair to Chrome. The specification was undergoing a lot of changes at the time, and V8 decided to wait for the specification to stabilize; meanwhile, Anba kept working on the implementation for FireFox. Additionally, the version of Temporal that Deno exposed last year was the heavily out of date to the most recent specification and had a large portion of the specification that was not even implemented.
- LegionMammal978 9mo agoI do find it annoying how the Temporal API, just like nearly all other datetime APIs, has 0 support for querying leap-second information in any shape or form. Suggested workarounds like temporal-tai all require plugging in a leap-second file and keeping it updated, which is especially painful for client-side JS, where you can't just download a leap-second file from someone else's site thanks to the SOP. Meanwhile, browsers update on a cadence more than sufficient to keep an up-to-date copy, but the datetime APIs refuse to expose leap-second info because they're too committed to "only UTC is in-scope for this project". (The context is that I want to write some JS tools for astronomical calculations, but UTC conversions need leap-second info, so this trend makes it impossible to write something that Just Works™.)
- nightpool 9mo ago> where you can't just download a leap-second file from someone else's site thanks to the SOP WDYM by this? Why does the SOP prevent a website from hosting a leap seconds file? All they need to do is set Access-Control-Allow-Origin to allow websites to access it. Or provide it as a JS file—in which case no headers are necessary at all. All the SOP prevents is you hotlinking someone else's leap-seconds file and using their bandwidth without their opt-in. > Meanwhile, browsers update on a cadence more than sufficient to keep an up-to-date copy Is this true? I don't know any browser right now that ships with a copy of a leapseconds data file. Adding such a data file and keeping it up to date would probably be a pretty non-trivial task for new browser developers—just for something the browser will never end up using itself. It's not like the ICU/CLDR files where browsers are going to need them anyway for rendering their own user-interface components.
- LegionMammal978 9mo ago> All they need to do is set Access-Control-Allow-Origin to allow websites to access it. All the SOP prevents is you hotlinking someone else's leap-seconds file and using their bandwidth without their opt-in. They can, but the major providers (read: the ones I would trust to update it) don't. The IERS doesn't [0], the USNO doesn't [1], IANA doesn't [2], and NIST uses FTP [3]. Keep in mind that these files are constantly being downloaded by various clients for NTP and whatnot, it's not like these providers want to restrict public access, they just don't bother to set the header that would allow JS requests. > Is this true? I don't know any browser right now that ships with a copy of a leapseconds data file. From ECMA-262: > It is required for time zone aware implementations (and recommended for all others) to use the time zone information of the IANA Time Zone Database https://www.iana.org/time-zones/ https://www.iana.org/time-zones/. Any browser that ships with a copy of tzdb, or knows where to find a copy from the OS, should have access to its leapseconds file. Unless you mean that all of them go solely through ICU and its data files? Which I suppose could be an obstacle unless ICU were to start exposing them. [0] https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list [1] https://maia.usno.navy.mil/ser7/tai-utc.dat https://maia.usno.navy.mil/ser7/tai-utc.dat [2] https://data.iana.org/time-zones/tzdb/leap-seconds.list https://data.iana.org/time-zones/tzdb/leap-seconds.list [3] ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list
- nchmy 9mo agoAnyone have links that indicate when Safari might have it?
- promiseofbeans 9mo agoThe JSC people have been relatively involved as the spec was developed, and they have it behind a flag in their TP builds . It’ll probably ship in Safari once it ships in Chrome so that their users don’t complain about broken websites
- devilsdata 9mo agoFor now, there's a polyfill: https://github.com/js-temporal/temporal-polyfill https://github.com/js-temporal/temporal-polyfill
- munificent 9mo ago> When an immutable value is assigned to a variable, the JavaScript engine creates a copy of that value and stores the copy in memory Not exactly. The language doesn't specify whether the value is copied or not and, precisely because values are immutable, there's no way for a user to tell if it was or wasn't. For example, strings are also immutable value types, but you can be certain that no JS engine is fully copying the entire string every time you assign one to a variable or pass it to a parameter.
- leeoniya 9mo agorelated: i had to jump through the Date hoops recently (again) when rewriting uPlot's DST and timezone handling, but i'm pretty happy with the result that avoided much complexity, performance loss, and adding a dependency: https://github.com/leeoniya/uPlot/pull/1072 https://github.com/leeoniya/uPlot/pull/1072 fun demos: https://leeoniya.github.io/uPlot/demos/timezones-dst.html https://leeoniya.github.io/uPlot/demos/timezones-dst.html
- procaryote 9mo agoThere's a lot wrong with Javascript's Date, but the fact that it's an object is is not really in the top 10. Would it have been nice if the Date object had been immutable? Sure, but the fact that changing the mutable object does indeed change the object shouldn't be a shock
- chowells 9mo agoIt's definitely a shock when something else changes the date object you've been holding on to. The problem with mutable values has never been when you (that is, the local context) change them. It's always that you can't trust that nothing else (some very non-local code) does.
- petesergeant 9mo agoThat’s how every other object works, why would that be surprising?
- kortilla 9mo agoThe lack of const means having objects as arguments is pretty dangerous
- ruszki 9mo agoWhat parent commenter meant was language level support of immutable objects. There is const, in for example JavaScript, but it supports only immutability of variables, not objects themselves. That later one is possible in C++ for example, where const can be used for both. Of course, it’s still possible to fake immutability with interfaces in some languages, or have a real one forced by implementation (like with Temporals), but it’s much nicer to have an indicator forcing that. I would like to add, that both variable and object immutability should be the default, and mutability should have a keyword, not other way around how in C++ and Java.
- arthens 9mo agoThat's a fair observation, and yet anecdotally I agree with the parent comment. In my career I fixed quite a few bugs about dates being passed around and unexpectedly modified, while I struggle to remember the same problem with objects in general (could be a case of selective memory). If I had the guess, I'd say it's a combination of: - the difference between the mental model and the implementation. Dates are objects but "feel" like values: dates are parsed from a single value, and when stored/printed they collapse back to a single value (as opposed to custom objects which are generally a bag of properties, and when printed/stored they still look like an object) - most common date operations causes the original date object to be mutated, which implicitly causes developers to mutate the passed value even if that's not what they explicitly meant So the default combination is a calling code that expects date to be treated as a value, and the called code accidentally mutating the data because it's convenient to do so. If anything then causes the original value to be saved back in the db, the data gets corrupted. Most experienced developers will remember to make a copy of the date object both in the calling code and in the receiving code, but the default remains dangerously easy to get wrong.
- TZubiri 9mo agoYes, you should use shiny new library instead of the glitchy javascript standard.. Unless you want your website to run in browsers older than a year Maybe in 10 years we can start using the shiny new thing?
- wesselbindt 9mo agoPolyfills are a thing, no?
- TZubiri 9mo agoSure, but you are adding an attack vector or two, and a couple of kilobytes.
- jrpelkonen 9mo agoSomewhat related: Jiff (https://github.com/BurntSushi/jiff https://github.com/BurntSushi/jiff) is a Rust library inspired by the Temporal api.
- nekevss 9mo agoThe library used for V8's temporal implementation is in Rust too ;)
- whiterook6 9mo agoSo, hold on--the author's soul-breaking complaint isn't all of the "quirks" and inconsistencies with the Date functions, but rather the fact that it's an object? Specifically, an object with mutable properties in a language when all objects have mutable properties? I mean, the author's conclusion is correct. But I disagree with the rationale. It's like hating an evil dictatorship because they use the wrong font in their propaganda.
- austin-cheney 9mo agoThe article is super weird. It never mentions Date.now(). It dances around the subject and exhaustively mentions the equivalent convention for Temporal. If you want Date to act like Temporal then only use Date.now() as your starting point. It generates the number of milliseconds since 1 Jan 1970. That means the starting output is a number type in integer form. It does not represent a static value, but rather the distance between now and some universal point in the past, a relationship. Yes, Temporal is a more friendly API, but the primary design goal is to represent time as a relational factor. Then you can format the Date.now() number it into whatever other format you want.
- ffsm8 9mo agothe article has examples of unexpected behavior with timestamps too, so... How do you covert to your desired format without going through Date? Please don't say date-fns
- austin-cheney 9mo agoI do not believe you understood the comment you replied to. A date number, whether from Date.now() or the Temporal equivalent, is not a time stamp value. It’s just a number.
- ffsm8 9mo agoThen I do not believe you understood the article you've commented on, because it essentially about the thing you handwaved away via > Then you can format the Date.now() number it into whatever other format you want. The while thing is about how to transition from a date, wherever it's string or timestamp to a date object. The idea is that you'll either format it to a string, do equality checks, calculate durations etc after after. Your idea of using timestamps doesn't address anything the article was about
- elendee 9mo agoI think the workflow your OP here and I use treats the timestamps (numbers) as the only value that matters. The "converted to" format is always just a temporary client side rendering, so the meticulous attention to conversions seems overkill. But I do see that there is tons of stuff about Date that is best ignored
- schiffern 9mo ago>It wholesale does not understand the concept of daylight savings time While we're nitpicking (which I wholly support, by the way) it's "daylight saving time." Cheers, great read.
- azornathogron 9mo agoEh... both are in common usage, including by institutions like the BBC. https://www.bbc.co.uk/future/article/20240308-daylight-savings-reasons-history-health-hazards-countries-that-abolished https://www.bbc.co.uk/future/article/20240308-daylight-savin... (you can find both "saving" and "savings" here, I guess they couldn't decide which to use?)
- pmarreck 9mo agoI actually had no idea javascript Date was this bad until now.
- acdha 9mo agoWhat’s really sad is that this was obvious in 1995. If they’d taken a slightly longer time back then, millions of developers would have avoided tripping over those unnecessary quirks.
- irjustin 9mo agoLate to the party, I really wish everyone would copy Rails + Ruby, but specifically it's Rails additions. 2 things it got right: 1. Like the article a great API - Time.current.in_time_zone('America/Los_Angeles') + 3.days - 4.months + 1.hour 2. Rails overloads Ruby's core library Time. You're in 1 object the whole time no swap/wondering. In the py world, pendulum is close but just like the article, it's cumbersome as it's still a separate obj (i.e. Temporal vs Date) and so you need to "figure out" what you have to manipulate or need to cast it first. Overloading the core libs is dangerous for a whole host of reasons but for the end developer it's a pleasure to use. If we could just do `new Date().add({ days: 1})` it would be so easier.
- publicdebates 9mo ago> 3.days - 4.months + 1.hour How is that a good thing? > Rails overloads Ruby's core library Time. You're in 1 object the whole time regardless of what you do. How is that a good thing?
- shermantanktop 9mo agoWhen what you have is a pickaxe, everything looks like a rail...
- happytoexplain 9mo ago>3.days - 4.months + 1.hour Is this what it looks like? A specific concept like time units being defined as members of more general types like numbers? I.e. if I type `1.` to get auto-complete, am I going to see days, and all the rest, as options?? That API design pattern would be a nightmare!
- greiskul 9mo agoIn Ruby, I assume this is done by monkey patching, so yes, it would have all the issues you mention and fear. In more modern languages like Kotlin, there is a notion of extension methods and properties, where you would be able to write a library that allows this syntax, but the .days property would only be accessible in files where you have explicitly imported it (so basically a synthetic sugar for a static function call).
- taf2 9mo agoIf only Safari had support for Temporal... maybe next year...
- devilsdata 9mo agoThere's a polyfill, I wonder if that works in Safari: https://github.com/js-temporal/temporal-polyfill https://github.com/js-temporal/temporal-polyfill
- atoav 9mo agoIf you ever find yourself in the situation where you have to decide whether 99 parses to year 1999 and what to do with 100 and where to draw the line between parsing the 90s and current years, you should probably pause, reath in andaout and take a long walk instead. And after you return you should scrap the whole thing and go back to the drawing board. Implementing such a feature has not only no value, it has negative value. When you program libraries or interfaces you ahould think aboit how people will use it 95% of the time and mane that usecase as simple, predictable and free of potential footguns as possible. This is the opposite of that. It feels like something 15 year old me would have programmed after reading the first book on PHP and not something anybosy with any experience could have thought to be a good thing.
- noduerme 9mo agoI use Moment. And a few years later, I'm still using Moment. And now I'm still using Moment. And now...
- mastermedo 9mo agoI dislike the "Plain" prefix to the temporal objects, e.g. PlainDateTime. The prefix says nothing about the behavior of the class. Plain as opposed to what; ZonedDateTime. I would prefer "Local" over "Plain"; LocalDateTime.
- exyi 9mo agoLocal would imply the date is in the current machine timezone, while PlainDateTime is zoneless. It may be in the server timezone, or anything else. The main difference is that it does not make sense to convert it to Instant or ZonedDateTime without specifying the timezone or offset
- agos 9mo agoyou have to consider the existence of PlainDate which is a Date without both a Time and a TimeZone
- Yaggo 9mo agoThe old JS Date API is far from perfect and I'm happy it being replaced, but part of the problem is various string-based formats and people being sloppy using them. Not to mention general complexity in time/date concept with timezones, summer time, leap seconds, etc. For string format, just stick with ISO 8601. If you need to parse less-standard formats, use a robust library of your choise. The standard library should not try to support parsing zillion obscure formats. Outputting localized / human-readable format should be a responsibility of localization API anyway. I also think that many libraries/APIs involving formatting things have some US centric design limitations, i.e. tendency to treat US formats as native and international support is often a bit after-thought. Especially with older stuff like the JS Date API.
- ReptileMan 9mo agoThe problem with the date format is that the US one absolutely totally insane. Whenever you use something ordered you have to choose ordering. For date US choose the absurd kind. Y-d-m should never have been used. Remove that and around 90% of the string based format problems disappear.
- devilsdata 9mo agoI live in Australia and we have d-m-Y, and even I would say just use ISO 8601. Just use the standard, please, pretty please with a cherry on top.
- lightningspirit 9mo agoIf you do `new Date('2025-11-31T00:00:00Z')` you get `2025-12-01T00:00:00.000Z`, which is weird and potential cause for bugs when parsing date string from input. Right because of these inconsistency I created a small package backed as Regex to validate Date string input before throwing it on `new Date(stringDate)`. https://www.npmjs.com/package/iso-8601-regex https://www.npmjs.com/package/iso-8601-regex
- jackfranklyn 9mo ago[flagged]
- GoblinSlayer 9mo ago>I've lost count of how many bugs I've shipped because Date silently converts everything to local time when you least expect it. You mean methods like getHours/getUTCHours?
- nubskr 9mo agoTemporal being immutable alone is worth whatever migration pain we're about to endure.
- krzkaczor 9mo agoI hope that we can move to using DurationLike objects in place of ms (or sometimes seconds?) as plain numbers like in `setInterval`. `sleep({seconds 5})` is so much better than `sleep(5000)`.
- recdnd 9mo agoTemporal feels less like a replacement for Date and more like an admission that Date was trying to represent too many different concepts at once.
- beeboop0 9mo ago[dead]
- mastermage 9mo agoAt one point we realy need to make web2. With a blank slate and maybe a much more sane implementation of Websites. Maybe just allow CSS Html and all functions need to run over Wasm. Wasm would need to get some more features for that but at least, you would avoid allot of bullshit.