Jump to content

Talk:Time formatting and storage bugs/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Merge from various articles

Per Wikipedia:Articles for deletion/Year 32,768 problem, I've created this page as a merge of

As of tonight, this is very rough, and mainly consists of copying the raw content from each of these articles. This is not the intended final result; I have plans for more edits in the near future to make this more coherent and less redundant, but I wanted to get the original content in the edit history.--NapoliRoma (talk) 06:40, 21 January 2008 (UTC)

Grouping under a single heading (more descriptive than 'Y2K and Y2K again') all the problems caused by using two digits to represent a year would be a good idea. Then Year 1900 problem and Year 2070 problem could also be merged into this article. Only Year 2000 problem really has sufficient unique content to warrant a separate article. —Safalra (talk) 12:25, 27 January 2008 (UTC)

Daylight Savings Time

I just spotted Year 2007 problem, which would seem to me to be a specific instance of the more generic problem of systems with hard-coded DST routines; this would seem to be another candidate to merge here.--NapoliRoma (talk) 15:06, 22 July 2008 (UTC)

13 bit GPS

The 13-bit GPS rollover seems to me to be Tuesday 2136-12-25 (to be adjusted for ignoring leap seconds) : if confirmed, that might as well be given. 82.163.24.100 (talk) 23:01, 22 January 2010 (UTC)

Years 2127 and 2255

Article has "The SPD EEPROM on modern computer memory modules contains a single-byte 2000-based year-of-manufacture code at offset 0x5D[5][6], which, depending on signed/unsigned interpretation, will wraparound on Dec 31 2127 or Dec 31 2255. Due to the 18-24 month generational cycle in computer technology this should not be a problem.". That is badly written. There is no problem in 2127 & 2255 (cf. Y2K), so Subject should be "Years 2128 and 2256". There is no wrap on Dec 31st; it occurs immediately after Dec 31st. 82.163.24.100 (talk) 11:37, 22 March 2010 (UTC)

2044

If the DOS datestamp is treated as a signed value, it rolls over at 2043/44. 82.163.24.100 (talk) 23:05, 22 January 2010 (UTC)

Yes, but it's not, it's an unsigned 7-bit bitfield within each directory entry. It will overflow in 2108. — Loadmaster (talk) 05:36, 26 January 2010 (UTC)
(Italic to differentiate between above and below) Wrong. The year is seven bits unsigned; the date stamp is 32 bits YYYYYYYMMMMDDDDD hhhhhmmmmmmsssss. The stamp will overflow on reaching 2108; but, if it is treated as signed (inevitable in systems with longint but not longword) the year will apparently go from 1980+63 to 1980-64 on reaching 2044. Direct 32-bit longint comparisons across 2043/44 will be in error; if longword is unavailable, one should use longint ones on (datestamp XOR $80000000). 82.163.24.100 (talk) 11:54, 22 March 2010 (UTC)
Which is discussed in the section "FAT filesystem date format (year 2108)" above. Even today, we do not use the FAT/DOS file system so much anymore, so it is no a big problem I assume. --BIL (talk) 10:13, 26 January 2010 (UTC)
(Italic to differentiate between above and below) Programs written for MSDOS will run unchanged in WinXP using COMMAND.COM or CMD.EXE, with a post-FAT file system. Their view of directory entries is as it always was, with one 32-bit datestamp. 82.163.24.100 (talk) 11:54, 22 March 2010 (UTC)
Actually FAT is used everywhere. Flash drives used in cameras, MP3 players, camcorders, USB memory sticks, etc. are almost all formatted FAT. The one place it's not used very much anymore is on hard drives (or on SSDs) - although even there it's hardly uncommon - many people who boot more than one OS have a FAT partition to ease moving data between those OS's. FAT support is basically universal, and thus is heavily used. FWIW, the basic ZIP file format uses the same two byte time and date formats (with the seven bit year) as does FAT, and I'm sure there are other places too. As to APIs, both MS-DOS (Int 21h / 4eh) and Win32/Win64 (via FileTimeToDosDateTime()) present the pair of two-byte fields in the format with a seven bit year. Given that it's explicitly a seven bit field in all these places (and thus requiring special handling from any code that needs to process it), I think the odds of someone mistakenly interpreting it as a *signed* seven bit field are slim. Rwessel (talk) 21:45, 26 January 2010 (UTC)
Remember that the 7-bit field is at the MS end of a YMD word and the MS end of a YMDhms longword. To compare dates for magnitude, one compares the word; to compare date/times, the longword. The problem will appear if, in either case, signed arithmetic is used; and that is a reasonably easy mistake to make. Especially if the language has longint but not longword (the fix is to XOR with 0x8000 or 0x8000000 before comparison; several times a day I use code containing that fix). I was usually 82.163.24.100; I now am usually 94.30.84.71 (talk) 22:22, 24 January 2011 (UTC).

FAT filesystem date format (year 2108)

The FAT filesystem date format (also used internally in ZIP files etc.) only goes until December 31st, 2107 (though some Microsoft operating systems reportedly only supported dates up through 2099)... AnonMoos (talk) 22:59, 26 March 2008 (UTC)

The ultimate limit is 2107-15-31 31:63:62, which works out as 2108-04-01 08:04:02 (UTC ignoring leap seconds?). 82.163.24.100 (talk) 22:56, 22 January 2010 (UTC)
So shouldn't this be in the article? I'd do it myself, but I'd rather someone with more authoritative knowledge do so (preferably with a cite, of course...)--NapoliRoma (talk) 17:26, 29 January 2011 (UTC)
Done. Rwessel (talk) 07:27, 31 January 2011 (UTC)
Does this problem include the FAT32 filesystem? The article FAT32 hints that it is so, should be mentioned here. The FAT filesystem, limited to 2 GB per partition is being phased out already. --BIL (talk) 08:24, 31 January 2011 (UTC)
FAT usually includes the very similar FAT12, FAT16 and FAT32, but not exFAT (which shares nothing with the usual FAT format except the three letters in its name and its origin within Microsoft). But the directory entry format for FAT12/16/32 is identical (with the exception of the reuse of another area for the two high bytes of the first cluster number), and all store years in the seven-bit format.
In any event FAT16 are not really going away. You cannot have a FAT32 volume of less than about 32MB, and exposing the storage on small devices as a flash drive is reasonably popular (and many of those have far less than 32MB of flash). Basically it allows a firmware update just by plugging the device into any USB port, and copying the new firmware to the “drive.” Even the internal flash on many current cameras is smaller than that (obviously before you add a flash card). True it's hard to find a "real" flash drive these days that's much smaller than 2GB, but those aren't the only uses. Rwessel (talk) 08:50, 31 January 2011 (UTC)

bolding of "year 32,768 problem" etc

I removed the bold from "year 32,768 problem" etc, on the grounds that such bolding violated WP:MOSBOLD. NapoliRoma restored the bolds with the comment that "the bolded terms are redirect targets", presumably complying with WP:R#PLA. However I assert that the reader will not be "astonished", because the terms mentioned are exactly what the redirect name was, and thus the bold is not necessary, as per the H2O example on WP:R#PLA. Mitch Ames (talk) 12:45, 16 February 2011 (UTC)

I was indeed thinking of WP:R#PLA. I'm not sure what you're saying here, since if you follow the guidance of WP:R#PLA and bold the redirected term, the term mentioned will indeed be exactly what the redirect name was. This seems to me to confirm the guidance in WP:R#PLA, not make it unnecessary.
So looking at WP:R#PLA, I'm confused about what the distinction is between the two examples: Tiptree/Sheldon and H2O. Why is Sheldon bolded and H2O not? Regards, NapoliRoma (talk) 22:26, 17 February 2011 (UTC)
It appears that the guideline's author is assuming that someone looking for "H2O" already knows that it is water. Whereas someone looking for Alice Sheldon might not realise that James Tiptree was the same person. I'm not so sure that the first assumption is valid. Mitch Ames (talk) 13:01, 18 February 2011 (UTC)

Adding of some of the topics together

I believe Days 32,768 and 65,536 and Years 32,768 and 65,536 should remain as one topic, they are both relying on the sane faults and are very similar. I have not time to edit right now, before I do in the future feel free to object. Yup (Talk? - Contribs?) 13:18, 14 June 2011 (UTC)

Bear in mind that although the storage problem is identical, the results my differ, because days is an offset, whereas year is an absolute value. So a year value of -1 might be displayed as "-1", which would generally be self-evidently wrong, but a day value of -1 might appear (for example if it is an offset from 1 January 1900) as 31 December 1899, which is not so obviously wrong, being a perfectly valid date. Mitch Ames (talk) 05:41, 16 June 2011 (UTC)

Other species of date bug

The bugs currently in the article all relate to the capacity of a storage field. Perhaps there should be a page on date bugs in general, linking of course to this page.

Examples include :

  • Daycount peculiarities originating with wrongly taking 1900 to have been a Leap Year.
  • Peculiar effects with fractional dates before 1899-12-30, stored as negative reals, because of the way div and mod work.
  • Easter date errors, due to misunderstandings, link to Computus
  • JavaScript limitation to 1970-01-01 ± 108 days GMT (the representation in milliseconds is stored in an IEEE Double; near the limit on the range in which a Double stores all integers exactly)
  • Mis-implementations : Safari 5.1 is often a day out for non-current days, seemingly due to including a three in the Leap Year coding - see in http://www.merlyn.demon.co.uk/js-datex.htm.
  • Ignoring the effects of offset from GMT and/or or seasonal changes

If such a page exists or is created, this article should link to it conspicuously. 94.30.84.71 (talk) 12:10, 24 September 2011 (UTC)

time zone for 2042

For IBM mainframes, P.Ops. specifies "ETR time" (External Time Reference) that's 10 seconds behind TAI. Not R (talk) 22:02, 14 September 2012 (UTC)

Fixed. Rwessel (talk) 18:52, 15 September 2012 (UTC)

Suggested Year 2042 section split

user:Tyranitar Man has suggesting splitting the section Time formatting and storage bugs#Year 2042 into its own article.

I'd point out that several other sections were created as merges of insufficiently notable articles (Year 32,768 problem, Year 65,536 problem, Year 292,277,026,596 problem and Year 170,141,183,460,469,231,731,687,303,715,884,105,727 problem). For completeness, I'll mention that Year 10,000 problem has survived several rounds at AfD. Also 2042 Problem already exists as a redirect, for consistency with the others, another at Year 2042 problem makes sense. Rwessel (talk) 10:35, 9 December 2012 (UTC)
Done. See Year 2042 problem. --Guy Macon (talk) 15:37, 9 December 2012 (UTC)
Should 2042 Problem be deleted? Rwessel (talk) 05:26, 10 December 2012 (UTC)
I don't disagree, but there appear to have been four failed attempts to have Year 10,000 problem deleted or merged already. My desire to stick my foot in that is minimal. In any event, it doesn't look like you got the merge proposal into that page, in case you're wanting to pursue itNever mind, you put it on the talk page, but didn't add a tag to the article page. Rwessel (talk) 05:26, 10 December 2012 (UTC)

libshadow and Tuesday, October 17, 2243

The libshadow is using six digits that are days to represent various expiry fields. The beginning of time is at January 1st, 1970. The Oct 17, 2243 is exactly one million days since the beginning of time _and_ the time of counter wrap. Whether this interests anyone, even as curiosity, is another question.

Sami Kerola (talk) 11:27, 2 January 2013 (UTC)

Second 1 Billion (S1B)

[1] 212.203.0.138 (talk) 06:20, 15 August 2014 (UTC)

I'd really like to see any evidence that this was an actual problem (either worried about before hand, or actual problems) ten years ago when this rollover happened. That the use of a 30 bits (not 29 bits as the link suggest) to store seconds-since-1970 was even remotely common seems quite an assumption. Rwessel (talk) 06:52, 15 August 2014 (UTC)

Unencyclopedic section heading

I recently changed the section heading "Problems" that aren't problems to "Problems", but my edit was reverted. I tried to change it because (a) The word "aren't" is a contraction which should be avoided, (b) The heading contradicts itself and (c) It sounds unencyclopedic (which I know is an overused term, but here I mean "doesn't sound professional"). The use of scare quotes is a bit weird and I would suggest, rather than what I originally changed it to, the heading Theoretical issues for the section. Since my edit has been reverted, I'd like to hear NapoliRoma's opinion and anyone else's. Do you agree the heading name should be changed? Do you like my suggestion of "Theoretical issues" or have your own to suggest, or think it's fine the way it is? — Bilorv(talk)(c)(e) 15:56, 5 February 2015 (UTC)

I don't think the current section title is bad, although I admit I may have had something to do with it. I know I've edited that section several times; memory just fails me if I've ever changed the title. Anyway losing the contraction is no problems, and the scare quotes around the first "problems" are not really inappropriate - they are not actually problems, after all. The title *is* a bit lighthearted, but then so are the "problems" (and they're probably more towards the silly end of the scale, but they nonetheless have gotten discussed). OTOH, I have no real objection to "Theoretical problems" either, although it does miss covering the part where these are used to indicate that it's specifically not a (practical) problem. Just "Problems" (with scare quotes), though, I thought was not an improvement. As I said, I've no objection to "Theoretical problems", but if it could be emphasized that these are *really* theoretical problems, I’d like that. Rwessel (talk) 18:18, 5 February 2015 (UTC)
I'm pretty sure the section heading's mine, dating back to when I first created the article... yep, it's from the fourth edit on the page.
It was of course fully intended to be at least a bit whimsical; as Rwessel noted, the subject of this section is not completely serious. (The article itself was created as the resolution to an AfD in part intended to delete several absurd articles; I chose to preserve the content matter, as having at least some mild entertainment value.)
My vote would be, unsurprisingly, to leave it the way it is. I think its meaning is clear: "problems" is in scare quotes because, well, they aren't really problems; the additional verbiage adds needed clarity as to just why the scare quotes are there. If the contraction is really an issue, spell it out! I do not think that would sound at all stilted. (But do note that the guideline says "avoid" rather than "exterminate".)
"Theoretical" is not entirely on point, as there is no question whether these are a problem or not. They are known, within any reasonable definition of "known", to not be a problem. If you really are compelled to change it, how about "Purely hypothetical problems"?
Or... consider this a vestigial remnant of when WP wasn't completely a Place Where Fun Went to Die, and leave it as is?--NapoliRoma (talk) 01:39, 7 February 2015 (UTC)

Hello fellow Wikipedians,

I have just modified one external link on Time formatting and storage bugs. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 01:02, 2 July 2016 (UTC)

Y10K and Beyond RFC

Do you think there should be a mention somewhere about [RFC 2550] - "Y10K and Beyond"? Although this is an "April 1st" parody RFC, it proposes a solution that, if implemented, actually does solve all of these "time formatting and storage bugs", at the expense of quite a bit of (unnecessary for most applications) software complexity. Shamino (talk) 16:16, 17 May 2018 (UTC)

I don't think the parody RFC deserves attention because software date standards normally encompass much more than the year. Normally at least the month and day are covered, and often the time of day and time zone. By the time Y10K becomes an issue, the Gregorian calendar will begin to b out of sync with the seasons, and society may decide to change it. Also, significant timekeeping changes will be required because of the ever more frequent leap seconds. Jc3s5h (talk) 17:25, 17 May 2018 (UTC)

Twitter's "Snowflake" IDs and 2075

Twitter uses a distributed ID system named "Snowflake", which consists of a 41-bit timestamp and 22 bits of other data. Twitter uses 2006-03-21 20:50:14.000 UTC as their epoch, so it will roll over on 2075-11-26 at 12:37:49.552 UTC. Discord uses a similar ID generation scheme with 42-bit timestamps (using the 64th bit of the ID for an explicit purpose) and an epoch of 2015-01-01 00:00:00.000 UTC, so their IDs will roll over on 2154-05-15 at 07:35:11.104 UTC. Maybe these should be included? — Preceding unsigned comment added by Nameless6144 (talk • contribs)

@Nameless6144: If you can find a reliable source with all of that information, then yes! they should be included, I highly encourage you to add the information if a reliable source does exist. —T.E.A. (Talk•Edits) 16:14, 25 March 2019 (UTC)

Date consistency

Parallelism is usually a good idea.

... this happened for the first time at 23:59:47 on Saturday 21 August 1999, the second time at 23:59:42 UTC on 6 April 2019 ...

One has the weekday, the other doesn't; one has UTC, the other doesn't. — MaxEnt 20:17, 16 April 2019 (UTC)

Years 9999, 20000 and 24613 (and a note)

In 9999 some systray icons be unclickable, and calendar randomly crashes.

In 20000, Windows 10 adds 1 to the year.

In 24613 Windows 10 stops working. See this video.

Note: At the 2080 problem, 1996 isn't the single solution, as one can use 2024 or 2052 in lieu of 2080.

Alfa-ketosav (talk) 11:46, 30 April 2019 (UTC)

Year 4501

According to this book, Microsoft Outlook stores the date 1 Jan 4501 instead of Null. It seems some other software (for example Google Picasa) use this date as an empty value (see the EXIF for this file, for example). Razvan Socol (talk) 13:25, 18 August 2019 (UTC)

"32,768" listed at Redirects for discussion

An editor has asked for a discussion to address the redirect 32,768. Please participate in the redirect discussion if you wish to do so. 14.207.205.207 (talk) 04:02, 10 January 2020 (UTC)

Avoiding TimeBugs

We might need higher resolution in future applications. ¿Why not start with the internal clock counting PlanckTimeUnits. We would have to use a 256-bit internal representation for the time. As a signed representation, the clock could handle takes out to 1*10^26 years in the future (I used only 1 significant figure because this is a ridiculously large number where the exact number of years is unimportant (all that one must understand is that it is big enough)). After we choose the 0-Time, we are set for the next 10^26 years with no need to mess with it. I propose that 00,000-01-01T00:00:00Z HE be the 0-Time. — Preceding unsigned comment added by 2601:643:C002:2830:D504:E45C:4C6D:894E (talk) 18:58, 8 August 2020 (UTC)

Year 2262 and C++ chrono::systemclock

The section of the article on 2262 is about storing time as nanoseconds since 1970 in signed 64-bit, which overflows on 11 April 2162. It lists C++ chrono::system_clock as having this problem, with a reference to https://en.cppreference.com/w/cpp/chrono/system_clock. But this reference does not talk about storage as nanoseconds in signed 64-bit. So I've flagged that ref as {{Failed verification}}. Does anyone have a better reference? netjeff (talk) 02:27, 12 March 2021 (UTC)

At the end of 2049, two digit email header years will fail

We note at the end of 2049, two digit email header years will fail. [2] Jidanni (talk) 13:27, 20 July 2021 (UTC)

"10,783,118,943,836,478,994,022,445,751,223" listed at Redirects for discussion

A discussion is taking place to address the redirect 10,783,118,943,836,478,994,022,445,751,223. The discussion will occur at Wikipedia:Redirects for discussion/Log/2021 September 8#10,783,118,943,836,478,994,022,445,751,223 until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Hog Farm Talk 05:19, 8 September 2021 (UTC)

Date-based version numbering is greater than signed 32-bit numbers in 2022

Services like Microsoft Exchange (on-premesis version) are apparently having problems because some related services use a YYMMDDhhmm format for versioning (screenshot). This is seemingly parsed as a 32-bit signed integer, which has a maximum value of 2,147,483,647 but 2022 dates become 2,2xx,xxx,xxx.

It's not a "time formatting and storage bug" in that it's not a Y2K-like bug. But there was a suggestion for Snowflake limits, which seem more closely related to this kind of "date as a version" problem.

Should this be included in this list? — Preceding unsigned comment added by IBBoard (talk • contribs) 11:38, 1 January 2022 (UTC)

Sorry I didn't see your entry here before adding it to the page (I'm new to editing wikipedia). For me this is clearly a "time formatting and storage bug" with the storage overflowing being 32 bit signed integers holding YYMMDDhhmm formatted strings by decimal conversion. The specific Microsoft bug might be versioning related, but underlying is a date overflow. Flocular (talk) 13:06, 1 January 2022 (UTC)

The following comment was added in a recent edit by user:207.81.187.41:

<!--or was it yymmdd0001 regardless of the value of HHMM?-->

The greatest 32-bit signed integer is, in hexadecimal notation, 7FFF FFFF. This is 2,147,483,647 in decimal. The last minute of 2021 would be written 2112312359, which is less than this, and the first minute of 2022 would be written 2201010000 which is greater than this. So it is essential that the hour and minute digits be included in order to cause the overflow. I will remove the HTML comment. Jc3s5h (talk) 16:57, 3 January 2022 (UTC)

Roman numerals

Isn't Roman numerals another cause of Year 4000 problem. Because largest Roman numeral is MMMCMXCIX or 3999. 89.236.252.20 (talk) 12:20, 7 April 2022 (UTC)

The Wikipedia article Roman numerals describes several ways of writing Roman numerals greater than 3999. Of course Wikipedia is not a reliable source, so if you want to pursue this, you could borrow some of the books listed in that article from the library, or buy them.
Writing Roman numerals greater than 3999 requires special characters that are not in the simplest computer character sets such as ASCII or EBCDIC, but modern computers are not limited to those character sets. Modern computers also have the ability to display an overline, which in the past has been used to indicate the Roman numeral under the line should be multiplied by 1000.
Roman numerals are in very limited use in computing, and computer software that supports them is limited in scope. But if a desire to work with large Roman numerals arises, conventions are available to accommodate the numbers. Jc3s5h (talk) 16:31, 7 April 2022 (UTC)

Weekdays of the Gregorian dates of 1 January 9999 BC and 31 December 9999

The proleptic Gregorian 1 January 9999 BC was a Monday (Julian 19 March 10000 BC). 31 December 9999, a Gregorian date, will be a Friday and "2958465" is its number. 189.69.67.242 (talk) 20:20, 16 September 2022 (UTC)

Year 292,277,026,296 problem

I'm assuming there's a particular reason that it is presumed 2^63 divided by the number of seconds in a year would equal 292,277,026,296. Something just doesn't seem right when below the statement that 2^(16 - 1) would become negative while 2^(64 - 1) would return to zero. Mechamind90 (talk) 20:27, 8 October 2009 (UTC)


Yep, those were mostly wrong. Now (hopefully) corrected. Rwessel (talk) 20:03, 9 October 2009 (UTC)

Okay, so what about the statement that it's past the end of the universe? Some red dwarfs currently in existence will still be shining then, if they aren't mined out first. —Preceding unsigned comment added by 211.27.152.145 (talk) 14:29, 2 March 2010 (UTC)

Yesterday, I added a [citation needed] to the section about humanity being dead by this date, and it was reverted. Perhaps that wasn't the correct way to go about it, as I am not an experienced Wikipedia editor, but I take issue with the way that it's worded. All 3 other points (earth, the sun, and the universe) have links to the section about the topic of their speculated final fate on their own pages, but the section about humanity lacks this, as if this was self-evident. Willytor (talk) 17:42, 28 December 2022 (UTC)

CE vs AD

This article uses CE in some places and AD in others. Is that okay or should it be edited to consistently use one or the other? 184.21.204.5 (talk) 02:40, 31 December 2022 (UTC)

Per MOS:ERA, an article should use one era style consistently. As far as I can see, currently this article has one use of AD and one use of CE, so it's not a huge issue, but it should be fixed. The AD was added here on 16 October 2020, and the CE was added here on 5 July 2022, so according to MOS:ERA, the older style should be retained, and the CE should be changed to AD. CodeTalker (talk) 02:58, 31 December 2022 (UTC)
Thank you! I changed the CE to AD, and also corrected the existing use of "292,277,026,596 AD" to "AD 292,277,026,596." 184.21.204.5 (talk) 03:29, 31 December 2022 (UTC)

"292,277,026,296" listed at Redirects for discussion

The redirect 292,277,026,296 has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 June 5 § 292,277,026,296 until a consensus is reached. GeoffreyT2000 (talk) 01:42, 5 June 2023 (UTC)

"584,554,051,223" listed at Redirects for discussion

The redirect 584,554,051,223 has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 June 5 § 584,554,051,223 until a consensus is reached. GeoffreyT2000 (talk) 01:42, 5 June 2023 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Time_formatting_and_storage_bugs/Archive_1&oldid=1253747651"