summaryrefslogtreecommitdiff
path: root/usr/src/man
diff options
context:
space:
mode:
Diffstat (limited to 'usr/src/man')
-rw-r--r--usr/src/man/man3c/Makefile38
-rw-r--r--usr/src/man/man3c/endian.3c191
-rw-r--r--usr/src/man/man3head/Makefile1
-rw-r--r--usr/src/man/man3head/endian.h.3head88
-rw-r--r--usr/src/man/man3socket/byteorder.3socket4
-rw-r--r--usr/src/man/man5/Makefile4
-rw-r--r--usr/src/man/man5/byteorder.5264
7 files changed, 588 insertions, 2 deletions
diff --git a/usr/src/man/man3c/Makefile b/usr/src/man/man3c/Makefile
index eebbda3288..61591de7e7 100644
--- a/usr/src/man/man3c/Makefile
+++ b/usr/src/man/man3c/Makefile
@@ -113,6 +113,7 @@ MANFILES= __fbufsize.3c \
enable_extended_FILE_stdio.3c \
encrypt.3c \
end.3c \
+ endian.3c \
epoll_create.3c \
epoll_ctl.3c \
epoll_wait.3c \
@@ -698,6 +699,12 @@ MANLINKS= FD_CLR.3c \
backtrace_symbols_fd.3c \
bcmp.3c \
bcopy.3c \
+ be16toh.3c \
+ be32toh.3c \
+ be64toh.3c \
+ betoh16.3c \
+ betoh32.3c \
+ betoh64.3c \
bind_textdomain_codeset.3c \
bindtextdomain.3c \
btowc_l.3c \
@@ -861,6 +868,12 @@ MANLINKS= FD_CLR.3c \
hasmntopt.3c \
hcreate.3c \
hdestroy.3c \
+ htobe16.3c \
+ htobe32.3c \
+ htobe64.3c \
+ htole16.3c \
+ htole32.3c \
+ htole64.3c \
initstate.3c \
innetgr.3c \
isalnum.3c \
@@ -934,6 +947,12 @@ MANLINKS= FD_CLR.3c \
labs.3c \
lcong48.3c \
ldiv.3c \
+ le16toh.3c \
+ le32toh.3c \
+ le64toh.3c \
+ letoh16.3c \
+ letoh32.3c \
+ letoh64.3c \
lfind.3c \
llabs.3c \
lldiv.3c \
@@ -1635,6 +1654,25 @@ _etext.3c := LINKSRC = end.3c
edata.3c := LINKSRC = end.3c
etext.3c := LINKSRC = end.3c
+be16toh.3c := LINKSRC = endian.3c
+be32toh.3c := LINKSRC = endian.3c
+be64toh.3c := LINKSRC = endian.3c
+betoh16.3c := LINKSRC = endian.3c
+betoh32.3c := LINKSRC = endian.3c
+betoh64.3c := LINKSRC = endian.3c
+htobe16.3c := LINKSRC = endian.3c
+htobe32.3c := LINKSRC = endian.3c
+htobe64.3c := LINKSRC = endian.3c
+htole16.3c := LINKSRC = endian.3c
+htole32.3c := LINKSRC = endian.3c
+htole64.3c := LINKSRC = endian.3c
+le16toh.3c := LINKSRC = endian.3c
+le32toh.3c := LINKSRC = endian.3c
+le64toh.3c := LINKSRC = endian.3c
+letoh16.3c := LINKSRC = endian.3c
+letoh32.3c := LINKSRC = endian.3c
+letoh64.3c := LINKSRC = endian.3c
+
epoll_create1.3c := LINKSRC = epoll_create.3c
epoll_pwait.3c := LINKSRC = epoll_wait.3c
diff --git a/usr/src/man/man3c/endian.3c b/usr/src/man/man3c/endian.3c
new file mode 100644
index 0000000000..5161af8fbd
--- /dev/null
+++ b/usr/src/man/man3c/endian.3c
@@ -0,0 +1,191 @@
+.\"
+.\" This file and its contents are supplied under the terms of the
+.\" Common Development and Distribution License ("CDDL"), version 1.0.
+.\" You may only use this file in accordance with the terms of version
+.\" 1.0 of the CDDL.
+.\"
+.\" A full copy of the text of the CDDL should have accompanied this
+.\" source. A copy of the CDDL is also available via the Internet at
+.\" http://www.illumos.org/license/CDDL.
+.\"
+.\"
+.\" Copyright 2016 Joyent, Inc.
+.\"
+.Dd January 30, 2016
+.Dt ENDIAN 3C
+.Os
+.Sh NAME
+.Nm endian ,
+.Nm be16toh ,
+.Nm be32toh ,
+.Nm be64toh ,
+.Nm betoh16 ,
+.Nm betoh32 ,
+.Nm betoh64 ,
+.Nm htobe16 ,
+.Nm htobe32 ,
+.Nm htobe64 ,
+.Nm htole16 ,
+.Nm htole32 ,
+.Nm htole64 ,
+.Nm le16toh ,
+.Nm le32toh ,
+.Nm le64toh ,
+.Nm letoh16 ,
+.Nm letoh32 ,
+.Nm letoh64
+.Nd convert between big and little endian byte order
+.Sh SYNOPSIS
+.In endian.h
+.Ft uint16_t
+.Fo be16toh
+.Fa "uint16_t be16"
+.Fc
+.Ft uint32_t
+.Fo be32toh
+.Fa "uint32_t be32"
+.Fc
+.Ft uint64_t
+.Fo betoh64
+.Fa "uint64_t be64"
+.Fc
+.Ft uint16_t
+.Fo betoh16
+.Fa "uint16_t be16"
+.Fc
+.Ft uint32_t
+.Fo betoh32
+.Fa "uint32_t be32"
+.Fc
+.Ft uint64_t
+.Fo be64toh
+.Fa "uint64_t be64"
+.Fc
+.Ft uint16_t
+.Fo htobe16
+.Fa "uint16_t host16"
+.Fc
+.Ft uint32_t
+.Fo htobe32
+.Fa "uint32_t host32"
+.Fc
+.Ft uint64_t
+.Fo htobe64
+.Fa "uint64_t host64"
+.Fc
+.Ft uint16_t
+.Fo htole16
+.Fa "uint16_t host16"
+.Fc
+.Ft uint32_t
+.Fo htole32
+.Fa "uint32_t host32"
+.Fc
+.Ft uint64_t
+.Fo htole64
+.Fa "uint64_t host64"
+.Fc
+.Ft uint16_t
+.Fo le16toh
+.Fa "uint16_t le16"
+.Fc
+.Ft uint32_t
+.Fo le32toh
+.Fa "uint32_t le32"
+.Fc
+.Ft uint64_t
+.Fo le64toh
+.Fa "uint64_t le64"
+.Fc
+.Ft uint16_t
+.Fo letoh16
+.Fa "uint16_t le16"
+.Fc
+.Ft uint32_t
+.Fo letoh32
+.Fa "uint32_t le32"
+.Fc
+.Ft uint64_t
+.Fo letoh64
+.Fa "uint64_t le64"
+.Fc
+.Sh DESCRIPTION
+The
+.Nm
+family of functions convert 16, 32, and 64-bit values between the host's
+native byte order and big- or little-endian. All of the functions in
+this family simply return their input when the host's native byte order
+is the same as the desired order. For more information on
+endianness, see
+.Xr byteorder 5 .
+.Pp
+The
+.Fn betoh16 ,
+.Fn betoh32 ,
+and
+.Fn betoh64
+functions take a 16-bit, 32-bit, or 64-bit value and convert it from
+big-endian to the host's native endianness, swapping bytes as required.
+.Pp
+The
+.Fn letoh16 ,
+.Fn letoh32 ,
+and
+.Fn letoh64
+functions take a 16-bit, 32-bit, or 64-bit value and convert it from
+little-endian to the host's native endianness, swapping bytes as
+required.
+.Pp
+The
+.Fn htobe16 ,
+.Fn htobe32 ,
+and
+.Fn htobe64
+functions take a 16-bit, 32-bit, or 64-bit value and convert it from
+the host's native endianness to big-endian, swapping bytes as required.
+.Pp
+The
+.Fn htole16 ,
+.Fn htole32 ,
+and
+.Fn htole64
+functions take a 16-bit, 32-bit, or 64-bit value and convert it from
+the host's native endianness to little-endian, swapping bytes as
+required.
+.Pp
+The functions
+.Fn be16toh ,
+.Fn be32toh ,
+.Fn be64toh ,
+.Fn le16toh ,
+.Fn le32toh ,
+and
+.Fn le64toh ,
+are the same as
+.Fn betoh16 ,
+.Fn betoh32 ,
+.Fn betoh64 ,
+.Fn letoh16 ,
+.Fn letoh32 ,
+and
+.Fn letoh64
+respectively. Historically, different platforms have diverged on the
+naming of these functions. To better support extant software, both are
+provided.
+.Pp
+While these functions are common across multiple platforms, they have
+not been standardized. Portable applications should instead use the
+functions defined in
+.Xr byteorder 3C .
+.Sh RETURN VALUES
+The functions always succeed and return a value that has been properly
+converted.
+.Sh INTERFACE STABILITY
+.Sy Committed
+.Sh MT-LEVEL
+.Sy MT-Safe
+.Sh SEE ALSO
+.Xr byteorder 3C ,
+.Xr endian.h 3HEAD ,
+.Xr attributes 5 ,
+.Xr byteorder 5
diff --git a/usr/src/man/man3head/Makefile b/usr/src/man/man3head/Makefile
index e53332b152..0e1c2efb17 100644
--- a/usr/src/man/man3head/Makefile
+++ b/usr/src/man/man3head/Makefile
@@ -27,6 +27,7 @@ MANFILES= acct.h.3head \
complex.h.3head \
cpio.h.3head \
dirent.h.3head \
+ endian.h.3head \
errno.h.3head \
fcntl.h.3head \
fenv.h.3head \
diff --git a/usr/src/man/man3head/endian.h.3head b/usr/src/man/man3head/endian.h.3head
new file mode 100644
index 0000000000..0fe5931751
--- /dev/null
+++ b/usr/src/man/man3head/endian.h.3head
@@ -0,0 +1,88 @@
+.\"
+.\" This file and its contents are supplied under the terms of the
+.\" Common Development and Distribution License ("CDDL"), version 1.0.
+.\" You may only use this file in accordance with the terms of version
+.\" 1.0 of the CDDL.
+.\"
+.\" A full copy of the text of the CDDL should have accompanied this
+.\" source. A copy of the CDDL is also available via the Internet at
+.\" http://www.illumos.org/license/CDDL.
+.\"
+.\"
+.\" Copyright 2016 Joyent, Inc.
+.\"
+.Dd January 30, 2016
+.Dt ENDIAN.H 3HEAD
+.Os
+.Sh NAME
+.Nm endian.h
+.Nd definitions for endian routines
+.Sh SYNOPSIS
+.In endian.h
+.Sh DESCRIPTION
+The
+.In endian.h
+header defines functions and macros focused on converting data between
+the host machines native byte order and big or little-endian values.
+While the manual page details the macros defined by
+.In endian.h ,
+the functions are documented separately in
+.Xr endian 3C.
+More information on endianness and a general background on the topic can
+be found in
+.Xr byteorder 5 .
+.Pp
+The
+.In endian.h
+header defines the following macros:
+.Bl -tag -width Ds
+.It Sy LITTLE_ENDIAN
+A constant used to indicate a little-endian integer. It is always
+defined, regardless of the actual endianess of the underlying platform.
+This macro should be used to compare against the
+.Sy BYTE_ORDER
+macro.
+.It Sy BIG_ENDIAN
+A constant used to indicate a big-endian integer. It is always defined,
+regardless of the actual endianess of the underlying platform. This
+macro should be used to compare against the
+.Sy BYTE_ORDER
+macro.
+.It Sy PDP_ENDIAN
+A constant used to indicate the endianness used for four byte values on
+the PDP-11. It is always defined, regardless of the actual endianess of
+the underlying platform. This macro should be used to compare against
+the
+.Sy BYTE_ORDER
+macro.
+.It Sy BYTE_ORDER
+The value of the
+.Sy BYTE_ORDER
+macro will be one of
+.Sy LITTLE_ENDIAN
+or
+.Sy BIG_ENDIAN .
+At this time, no supported architectures use the byte order indicated by
+the
+.Sy PDP_ENDIAN
+macro.
+.Pp
+To determine the byte order of a system, one may compare the
+.Sy BYTE_ORDER
+to one of the aforementioned macros.
+.El
+.Pp
+In addition to the routines provided by this header, standardized
+functions may be found in
+.Xr byteorder 3C .
+The header
+.Xr types.h 3HEAD
+also defines additional pre-processor symbols to determine the current
+endianness of the system.
+.Sh INTERFACE STABILITY
+.Sy Committed
+.Sh SEE ALSO
+.Xr endian 3C ,
+.Xr types.h 3HEAD ,
+.Xr attributes 5 ,
+.Xr byteorder 5
diff --git a/usr/src/man/man3socket/byteorder.3socket b/usr/src/man/man3socket/byteorder.3socket
index bb5e22fc46..1d08cd8204 100644
--- a/usr/src/man/man3socket/byteorder.3socket
+++ b/usr/src/man/man3socket/byteorder.3socket
@@ -4,7 +4,7 @@
.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License.
.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
-.TH BYTEORDER 3SOCKET "Nov 23, 2015"
+.TH BYTEORDER 3SOCKET "Mar 10, 2016"
.SH NAME
byteorder, htonl, htonll, htons, ntohl, ntohll, ntohs \- convert values between
host and network byte order
@@ -74,4 +74,4 @@ MT-Level Safe
.SH SEE ALSO
.LP
\fBgethostbyname\fR(3NSL), \fBgetservbyname\fR(3SOCKET), \fBinet.h\fR(3HEAD),
-\fBattributes\fR(5)
+\fBattributes\fR(5), \fBbyteorder\fR(5)
diff --git a/usr/src/man/man5/Makefile b/usr/src/man/man5/Makefile
index c30af8e1d1..71ed86715f 100644
--- a/usr/src/man/man5/Makefile
+++ b/usr/src/man/man5/Makefile
@@ -30,6 +30,7 @@ MANFILES= Intro.5 \
audit_remote.5 \
audit_syslog.5 \
brands.5 \
+ byteorder.5 \
cancellation.5 \
charmap.5 \
condition.5 \
@@ -154,6 +155,7 @@ MANLINKS= ANSI.5 \
architecture.5 \
availability.5 \
compile.5 \
+ endian.5 \
intro.5 \
pthreads.5 \
stability.5 \
@@ -170,6 +172,8 @@ availability.5 := LINKSRC = attributes.5
stability.5 := LINKSRC = attributes.5
standard.5 := LINKSRC = attributes.5
+endian.5 := LINKSRC = byteorder.5
+
RBAC.5 := LINKSRC = rbac.5
advance.5 := LINKSRC = regexp.5
diff --git a/usr/src/man/man5/byteorder.5 b/usr/src/man/man5/byteorder.5
new file mode 100644
index 0000000000..4172008e97
--- /dev/null
+++ b/usr/src/man/man5/byteorder.5
@@ -0,0 +1,264 @@
+.\"
+.\" This file and its contents are supplied under the terms of the
+.\" Common Development and Distribution License ("CDDL"), version 1.0.
+.\" You may only use this file in accordance with the terms of version
+.\" 1.0 of the CDDL.
+.\"
+.\" A full copy of the text of the CDDL should have accompanied this
+.\" source. A copy of the CDDL is also available via the Internet at
+.\" http://www.illumos.org/license/CDDL.
+.\"
+.\"
+.\" Copyright 2016 Joyent, Inc.
+.\"
+.Dd January 31, 2016
+.Dt BYTEORDER 5
+.Os
+.Sh NAME
+.Nm byteorder ,
+.Nm endian
+.Nd byte order and endianness
+.Sh DESCRIPTION
+Integer values which occupy more than 1 byte in memory can be laid out
+in different ways on different platforms. In particular, there is a
+major split between those which place the least significant byte of an
+integer at the lowest address, and those which place the most
+significant byte there instead. As this difference relates to which
+end of the integer is found in memory first, the term
+.Em endian
+is used to refer to a particular byte order.
+.Pp
+A platform is referred to as using a
+.Em big-endian
+byte order when it places the most significant byte at the lowest
+address, and
+.Em little-endian
+when it places the least significant byte first. Some platforms may also
+switch between big- and little-endian mode and run code compiled for
+either.
+.Pp
+Historically, there have also been some systems that utilized
+.Em middle-endian
+byte orders for integers larger than 2 bytes. Such orderings are not in
+common use today.
+.Pp
+Endianness is also of particular importance when dealing with values
+that are being read into memory from an external source. For example,
+network protocols such as IP conventionally define the fields in a
+packet as being always stored in big-endian byte order. This means that
+a little-endian machine will have to perform transformations on these
+fields in order to process them.
+.Ss Examples
+To illustrate endianness in memory, let us consider the decimal integer
+2864434397. This number fits in 32 bits of storage (4 bytes).
+.Pp
+On a big-endian system, this integer would be written into memory as
+the bytes 0xAA, 0xBB, 0xCC, 0xDD, in order from lowest memory address to
+highest.
+.Pp
+On a little-endian system, it would be written instead as the bytes
+0xDD, 0xCC, 0xBB, 0xAA, in that order.
+.Pp
+If both the big- and little-endian systems were asked to store this
+integer at address 0x100, we would see the following in each of their
+memory:
+.Bd -literal
+
+ Big-Endian
+
+ ++------++------++------++------++
+ || 0xAA || 0xBB || 0xCC || 0xDD ||
+ ++------++------++------++------++
+ ^^ ^^ ^^ ^^
+ 0x100 0x101 0x102 0x103
+ vv vv vv vv
+ ++------++------++------++------++
+ || 0xDD || 0xCC || 0xBB || 0xAA ||
+ ++------++------++------++------++
+
+ Little-Endian
+.Ed
+.Pp
+It is particularly important to note that even though the byte order is
+different between these two machines, the bit ordering within each byte,
+by convention, is still the same.
+.Pp
+For example, take the decimal integer 4660, which occupies in 16 bits (2
+bytes).
+.Pp
+On a big-endian system, this would be written into memory as 0x12, then
+0x34.
+.Pp
+On a little-endian system, it would be written as 0x34, then 0x12. Note
+that this is not at all the same as seeing 0x43 then 0x21 in memory --
+only the bytes are re-ordered, not any bits (or nybbles) within them.
+.Pp
+As before, storing this at address 0x100:
+.Bd -literal
+ Big-Endian
+
+ ++------++------++
+ || 0x12 || 0x34 ||
+ ++------++------++
+ ^^ ^^
+ 0x100 0x101
+ vv vv
+ ++------++------++
+ || 0x34 || 0x12 ||
+ ++------++------++
+
+ Little-Endian
+.Ed
+.Pp
+This example shows how an eight byte number, 0xBADCAFEDEADBEEF is stored
+in both big and little-endian:
+.Bd -literal
+ Big-Endian
+
+ +------+------+------+------+------+------+------+------+
+ | 0xBA | 0xDC | 0xAF | 0xFE | 0xDE | 0xAD | 0xBE | 0xEF |
+ +------+------+------+------+------+------+------+------+
+ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^
+ 0x100 0x101 0x102 0x103 0x104 0x105 0x106 0x107
+ vv vv vv vv vv vv vv vv
+ +------+------+------+------+------+------+------+------+
+ | 0xEF | 0xBE | 0xAD | 0xDE | 0xFE | 0xAF | 0xDC | 0xBA |
+ +------+------+------+------+------+------+------+------+
+
+ Little-Endian
+
+.Ed
+.Pp
+The treatment of different endian values would not be complete without
+discussing
+.Em PDP-endian ,
+which is also known as
+.Em middle-endian .
+While the PDP-11 was a 16-bit little-endian system, it laid out 32-bit
+values in a different way from current little-endian systems. First, it
+would divide a 32-bit number into two 16-bit numbers. Each 16-bit number
+would be stored in little-endian; however, the two 16-bit words would be
+stored with the larger 16-bit word appearing first in memory, followed
+by the latter.
+.Pp
+The following image illustrates PDP-endian and compares it against
+little-endian values. Here, we'll start with the value 0xAABBCCDD and
+show how the four bytes for it will be laid out, starting at 0x100.
+.Bd -literal
+ PDP-Endian
+
+ ++------++------++------++------++
+ || 0xBB || 0xAA || 0xDD || 0xCC ||
+ ++------++------++------++------++
+ ^^ ^^ ^^ ^^
+ 0x100 0x101 0x102 0x103
+ vv vv vv vv
+ ++------++------++------++------++
+ || 0xDD || 0xCC || 0xBB || 0xAA ||
+ ++------++------++------++------++
+
+ Little-Endian
+
+.Ed
+.Ss Network Byte Order
+The term 'network byte order' refers to big-endian ordering, and
+originates from the IEEE. Early disagreements over which byte ordering
+to use for network traffic prompted RFC1700 to define that all
+IETF-specified network protocols use big-endian ordering unless noted
+explicitly otherwise. The Internet protocol family (IP, and thus TCP and
+UDP etc) particularly adhere to this convention.
+.Ss Determining the System's Byte Order
+The operating system supports both big-endian and little-endian CPUs. To
+make it easier for programs to determine the endianness of the
+platform they are being compiled for, functions and macro constants are
+provided in the system header files.
+.Pp
+The endianness of the system can be obtained by including the header
+.In sys/types.h
+and using the pre-processor macros
+.Sy _LITTLE_ENDIAN
+and
+.Sy _BIG_ENDIAN .
+See
+.Xr types.h 3HEAD
+for more information.
+.Pp
+Additionally, the header
+.In endian.h
+defines an alternative means for determining the endianness of the
+current system. See
+.Xr endian.h 3HEAD
+for more information.
+.Pp
+illumos runs on both big- and little-endian systems. When writing
+software for which the endianness is important, one must always check
+the byte order and convert it appropriately.
+.Ss Converting Between Byte Orders
+The system provides two different sets of functions to convert values
+between big-endian and little-endian. They are defined in
+.Xr byteorder 3C
+and
+.Xr endian 3C .
+.Pp
+The
+.Xr byteorder 3SOCKET
+family of functions convert data between the host's native byte order
+and big- or little-endian.
+The functions operate on either 16-bit, 32-bit, or 64-bit values.
+Functions that convert from network byte order to the host's byte order
+start with the string
+.Sy ntoh ,
+while functions which convert from the host's byte order to network byte
+order, begin with
+.Sy hton .
+For example, to convert a 32-bit value, a long, from network byte order
+to the host's, one would use the function
+.Xr ntohl 3SOCKET .
+.Pp
+These functions have been standardized by POSIX. However, the 64-bit variants,
+.Xr ntohll 3SOCKET
+and
+.Xr htonll 3SOCKET
+are not standardized and may not be found on other systems. For more
+information on these functions, see
+.Xr byteorder 3SOCKET .
+.Pp
+The second family of functions,
+.Xr endian 3C ,
+provide a means to convert between the host's byte order
+and big-endian and little-endian specifically. While these functions are
+similar to those in
+.Xr byteorder 3C ,
+they more explicitly cover different data conversions. Like them, these
+functions operate on either 16-bit, 32-bit, or 64-bit values. When
+converting from big-endian, to the host's endianness, the functions
+begin with
+.Sy betoh .
+If instead, one is converting data from the host's native endianness to
+another, then it starts with
+.Sy htobe .
+When working with little-endian data, the prefixes
+.Sy letoh
+and
+.Sy htole
+convert little-endian data to the host's endianness and from the host's
+to little-endian respectively.
+.Pp
+These functions
+are not standardized and the header they appear in varies between the
+BSDs and GNU/Linux. Applications that wish to be portable, should
+instead use the
+.Xr byteorder 3C
+functions.
+.Pp
+All of these functions in both families simply return their input when
+the host's native byte order is the same as the desired order. For
+example, when calling
+.Xr htonl 3SOCKET
+on a big-endian system the original data is returned with no conversion
+or modification.
+.Sh SEE ALSO
+.Xr endian 3C ,
+.Xr endian.h 3HEAD ,
+.Xr inet 3HEAD ,
+.Xr byteorder 3SOCKET
generated by cgit v1.2.3 (git 2.46.0) at 2025-10-22 06:47:53 +0000