Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-21 08:33:19 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibJS/Runtime/Intl/DateTimeFormatFunction.h

35 lines
856 B
C
Raw Normal View History

LibJS: Implement (most of) Intl.DateTimeFormat.prototype.format There are a few FIXMEs that will need to be addressed, but this implements most of the prototype method. The FIXMEs are mostly related to range formatting, which has been entirely ignored so far. But other than that, the following will need to be addressed: * Determining flexible day periods must be made locale-aware. * DST will need to be determined and acted upon. * Time zones other than UTC and calendars other than Gregorian are ignored. * Some of our results differ from other engines as they have some format patterns we do not. For example, they seem to have a lonely {dayPeriod} pattern, whereas our closest pattern is "{hour} {dayPeriod}".
2021-12-06 12:26:49 -05:00
/*
Everywhere: Update copyrights with my new serenityos.org e-mail :^)
2022-01-31 13:07:22 -05:00
* Copyright (c) 2021, Tim Flynn <trflynn89@serenityos.org>
LibJS: Implement (most of) Intl.DateTimeFormat.prototype.format There are a few FIXMEs that will need to be addressed, but this implements most of the prototype method. The FIXMEs are mostly related to range formatting, which has been entirely ignored so far. But other than that, the following will need to be addressed: * Determining flexible day periods must be made locale-aware. * DST will need to be determined and acted upon. * Time zones other than UTC and calendars other than Gregorian are ignored. * Some of our results differ from other engines as they have some format patterns we do not. For example, they seem to have a lonely {dayPeriod} pattern, whereas our closest pattern is "{hour} {dayPeriod}".
2021-12-06 12:26:49 -05:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <LibJS/Forward.h>
#include <LibJS/Runtime/Completion.h>
#include <LibJS/Runtime/NativeFunction.h>
namespace JS::Intl {
class DateTimeFormatFunction final : public NativeFunction {
JS_OBJECT(DateTimeFormatFunction, NativeFunction);
public:
LibJS: Convert Intl::DateTimeFormatFunction::create() to NonnullGCPtr
2022-12-13 20:49:50 +00:00
static NonnullGCPtr<DateTimeFormatFunction> create(Realm&, DateTimeFormat&);
LibJS: Implement (most of) Intl.DateTimeFormat.prototype.format There are a few FIXMEs that will need to be addressed, but this implements most of the prototype method. The FIXMEs are mostly related to range formatting, which has been entirely ignored so far. But other than that, the following will need to be addressed: * Determining flexible day periods must be made locale-aware. * DST will need to be determined and acted upon. * Time zones other than UTC and calendars other than Gregorian are ignored. * Some of our results differ from other engines as they have some format patterns we do not. For example, they seem to have a lonely {dayPeriod} pattern, whereas our closest pattern is "{hour} {dayPeriod}".
2021-12-06 12:26:49 -05:00
virtual ~DateTimeFormatFunction() override = default;
LibJS+Everywhere: Allow Cell::initialize overrides to throw OOM errors Note that as of this commit, there aren't any such throwers, and the call site in Heap::allocate will drop exceptions on the floor. This commit only serves to change the declaration of the overrides, make sure they return an empty value, and to propagate OOM errors frm their base initialize invocations.
2023-01-28 12:33:35 -05:00
virtual ThrowCompletionOr<void> initialize(Realm&) override;
LibJS: Implement (most of) Intl.DateTimeFormat.prototype.format There are a few FIXMEs that will need to be addressed, but this implements most of the prototype method. The FIXMEs are mostly related to range formatting, which has been entirely ignored so far. But other than that, the following will need to be addressed: * Determining flexible day periods must be made locale-aware. * DST will need to be determined and acted upon. * Time zones other than UTC and calendars other than Gregorian are ignored. * Some of our results differ from other engines as they have some format patterns we do not. For example, they seem to have a lonely {dayPeriod} pattern, whereas our closest pattern is "{hour} {dayPeriod}".
2021-12-06 12:26:49 -05:00
virtual ThrowCompletionOr<Value> call() override;
private:
LibJS: Hide all the constructors! Now that the GC allocator is able to invoke Cell subclass constructors directly via friendship, we no longer need to keep them public. :^)
2022-08-28 23:51:28 +02:00
explicit DateTimeFormatFunction(DateTimeFormat&, Object& prototype);
LibJS: Implement (most of) Intl.DateTimeFormat.prototype.format There are a few FIXMEs that will need to be addressed, but this implements most of the prototype method. The FIXMEs are mostly related to range formatting, which has been entirely ignored so far. But other than that, the following will need to be addressed: * Determining flexible day periods must be made locale-aware. * DST will need to be determined and acted upon. * Time zones other than UTC and calendars other than Gregorian are ignored. * Some of our results differ from other engines as they have some format patterns we do not. For example, they seem to have a lonely {dayPeriod} pattern, whereas our closest pattern is "{hour} {dayPeriod}".
2021-12-06 12:26:49 -05:00
virtual void visit_edges(Visitor&) override;
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
NonnullGCPtr<DateTimeFormat> m_date_time_format; // [[DateTimeFormat]]
LibJS: Implement (most of) Intl.DateTimeFormat.prototype.format There are a few FIXMEs that will need to be addressed, but this implements most of the prototype method. The FIXMEs are mostly related to range formatting, which has been entirely ignored so far. But other than that, the following will need to be addressed: * Determining flexible day periods must be made locale-aware. * DST will need to be determined and acted upon. * Time zones other than UTC and calendars other than Gregorian are ignored. * Some of our results differ from other engines as they have some format patterns we do not. For example, they seem to have a lonely {dayPeriod} pattern, whereas our closest pattern is "{hour} {dayPeriod}".
2021-12-06 12:26:49 -05:00
};
}
Reference in a new issue Copy permalink