On Friday, 4 March 2022 at 23:09:19 UTC, Siri Cruise wrote:
> In article <874k4d8...@tigger.extechop.net>,
> o...@iki.fi (Otto J. Makela) wrote:
>
> > The mains frequency is a rather good timebase: the base frequency (be it
> > 50 or 60 Hz) is very rigidly maintained, because otherwise the whole
> > interconnected power network would very quickly fall apart.
> How can that be true? All the experts are chiming in that it's
> impossible to have a stanardised and rigidly adhered to anything
> about the grid.
>
When I was a child we lived over the road from a supermarket.
The telly would blank out when they turned their ovens on due to the
load on the grid.

On 2022-03-04 Siri Cruise wrote in comp.lang.c:
> In article <874k4d8ojg.fsf@tigger.extechop.net>,
> om@iki.fi (Otto J. Makela) wrote:
>
>> The mains frequency is a rather good timebase: the base frequency (be it
>> 50 or 60 Hz) is very rigidly maintained, because otherwise the whole
>> interconnected power network would very quickly fall apart.
>
> How can that be true? All the experts are chiming in that it's
> impossible to have a stanardised and rigidly adhered to anything
> about the grid.

Mains frequency is tightly controlled:
https://en.wikipedia.org/wiki/Utility_frequency#Time_error_correction_(TEC)

Load variations can cause short-time variations, but average frequency
is maintained. At least in normal conditions. A while back a few Balkan
countries did not supply their promised amount of electricity, causing a
slight drop in frequency in Europe for months. This caused all clocks
that use mains for their time base to lag by 6 minutes.

--
Stef

Thank god!! ... It's HENNY YOUNGMAN!!

Siri Cruise <chine.bleu@yahoo.com> writes:
> In article <874k4d8ojg.fsf@tigger.extechop.net>,
> om@iki.fi (Otto J. Makela) wrote:
>
>> The mains frequency is a rather good timebase: the base frequency (be it
>> 50 or 60 Hz) is very rigidly maintained, because otherwise the whole
>> interconnected power network would very quickly fall apart.

> How can that be true?

Because a lot of people did a lot of work to make it true. It's not my
area of expertise, so I don't know the details. It also has nothing to
do with C, so if you want to learn more about it I suggest going
elsewhere.

> All the experts are chiming in that it's
> impossible to have a stanardised and rigidly adhered to anything
> about the grid.

Literally no experts have said that. Stop trolling.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 3/4/2022 2:12 PM, Otto J. Makela wrote:
> Dan Purgert <dan@djph.net> wrote:
>
>> I guess we can say I've lost the plot somewhere then -- I just can't
>> piece together how this would improve "timekeeping" on a device
>> plugged into the mains.
>
> The mains frequency is a rather good timebase: the base frequency (be it
> 50 or 60 Hz) is very rigidly maintained, because otherwise the whole
> interconnected power network would very quickly fall apart.
>
> https://www.mainsfrequency.com/gridtime.php

Don't forget the DC grid, mostly grid interconnects.

And ERCOT in Texas tells people to not run their clocks based on the
frequency even though all AC clocks use the frequency for their timeliness.

Lynn

In article <svuca0$f70$1@dont-email.me>,
Lynn McGuire <lynnmcguire5@gmail.com> wrote:

> And ERCOT in Texas tells people to not run their clocks based on the

So Texas supplies residential and business customer DC instead of
AC? Do they also replace on devices expecting AC?

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

In article <871qzhmdpj.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> > All the experts are chiming in that it's
> > impossible to have a stanardised and rigidly adhered to anything
> > about the grid.
>
> Literally no experts have said that. Stop trolling.

Do say. Thanks for confirming my long held opinion of the kind of
people who enjoy attacking newbies.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

In article <nnd$0ce3b333$1344114e@5e8aa6fcc0002811>,
Stef <me@this.is.invalid> wrote:

> > How can that be true? All the experts are chiming in that it's
> > impossible to have a stanardised and rigidly adhered to anything
> > about the grid.
>
> Mains frequency is tightly controlled:

No shit. But what about all the experts who chimed in that
message passing on an AC grid was impossible because all the
different operators made it too chaotic?

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

On 3/4/2022 7:49 PM, Siri Cruise wrote:
> In article <svuca0$f70$1@dont-email.me>,
> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>
>> And ERCOT in Texas tells people to not run their clocks based on the
>
> So Texas supplies residential and business customer DC instead of
> AC? Do they also replace on devices expecting AC?

There is no residential DC in Texas that I know of. Most of the DC
grids around the world are for old electric train systems as modern
electric train systems run on AC.

Lynn

On 04/03/2022 16:44, Dan Purgert wrote:
> David Brown wrote:
>> On 04/03/2022 15:31, Dan Purgert wrote:
>>>
>>> Honestly though, even using the AC line sounds like its adding
>>> complexity for little (or no) benefit to my oven/microwave/etc. Also,
>>> how's it gonna handle different line frequency? As a manufacturer, am I
>>> gonna need half a dozen different designs of the same product to
>>> accommodate line frequency?
>
>> There are only two frequencies used - 50 Hz and 60 Hz. It's not hard to
>> make automatic detection of which of these you are seeing, as you always
>> have some kind of frequency reference for your microcontroller.
>
> Whoops, that was supposed to be "multiple", not "half a dozen". Thought
> process collisions are just wonderful, aren't they.
>

I thought it was a perfectly reasonable question. I've done this kind
of thing, but most programmers haven't been anywhere near such
electronics questions and thus don't have the experience to know what
might be easy or hard in practice.

> I guess we can say I've lost the plot somewhere then -- I just can't
> piece together how this would improve "timekeeping" on a device plugged
> into the mains.
>

A microcontroller can use the AC line frequency for a reference for the
price of one resistor, so it will give you better long-term drift
accuracy for your money than using a crystal oscillator reference. It
is thus quite common practice for things like kitchen appliances that
have a simple clock.

On 05/03/2022 02:54, Siri Cruise wrote:
> In article <nnd$0ce3b333$1344114e@5e8aa6fcc0002811>,
> Stef <me@this.is.invalid> wrote:
>
>>> How can that be true? All the experts are chiming in that it's
>>> impossible to have a stanardised and rigidly adhered to anything
>>> about the grid.
>>
>> Mains frequency is tightly controlled:
>
> No shit. But what about all the experts who chimed in that
> message passing on an AC grid was impossible because all the
> different operators made it too chaotic?
>

The AC frequency is fundamental to the way AC power distribution works -
it has nothing at all to do with sending additional messages on top of
the power lines!

On 05/03/2022 04:49, Lynn McGuire wrote:
> On 3/4/2022 7:49 PM, Siri Cruise wrote:
>> In article <svuca0$f70$1@dont-email.me>,
>>   Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>
>>> And ERCOT in Texas tells people to not run their clocks based on the
>>
>> So Texas supplies residential and business customer DC instead of
>> AC? Do they also replace on devices expecting AC?
>
> There is no residential DC in Texas that I know of.  Most of the DC
> grids around the world are for old electric train systems as modern
> electric train systems run on AC.
>

DC grids are also used for longer distance and higher power, because
they are significantly more efficient than AC. However, they are more
complex to switch on and off, or to transform the voltages. But you
don't need to synchronise the phase and frequency between generators.

Of course, you can't then use the line frequency for your clocks!

On 04/03/2022 16:54, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 04/03/2022 15:31, Dan Purgert wrote:
>>> David Brown wrote:
>>>> [...]
>>>> But any kind of data reception - radio, power-line, whatever - costs
>>>> money, power, space and complexity at the receiving end. Counting AC
>>>> cycles is by far the cheapest and simplest solution when you are plugged
>>>> in, and is stable over the long term but has no absolute reference.
>>>
>>> And my microwave doesn't need an absolute reference either.
>>>
>>> Honestly though, even using the AC line sounds like its adding
>>> complexity for little (or no) benefit to my oven/microwave/etc. Also,
>>> how's it gonna handle different line frequency? As a manufacturer, am I
>>> gonna need half a dozen different designs of the same product to
>>> accommodate line frequency?
>>
>> There are only two frequencies used - 50 Hz and 60 Hz. It's not hard to
>> make automatic detection of which of these you are seeing, as you always
>> have some kind of frequency reference for your microcontroller.
>
> Although with modern switching power supplies, the AC mains frequency is
> pretty much irrelevent and certainly not visible downstream of the
> power supply.
>

You don't use it for things plugged into small DC power supplies - you
use it in things that use higher power, such as the ovens and microwaves
that were mentioned.

It is possible to have an antenna in your DC-powered (or battery
powered) equipment to pick up the 50/60 Hz "hum" that is found anywhere
that mains electricity is used, but I haven't seen that as a technique
for timing reference.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Otto J. Makela wrote:
> Dan Purgert <dan@djph.net> wrote:
>
>> I guess we can say I've lost the plot somewhere then -- I just can't
>> piece together how this would improve "timekeeping" on a device
>> plugged into the mains.
>
> The mains frequency is a rather good timebase: the base frequency (be it
> 50 or 60 Hz) is very rigidly maintained, because otherwise the whole
> interconnected power network would very quickly fall apart.

Okay, so it's what I had thought - it's "just another clock source" in
addition to whatever crystal oscillator (etc.) source that a
microcontroller is (likely) already using.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIjWrkACgkQbWVw5Uzn
KGDsOQ//XGfSsTHKV4M9hs4VISIe01fWC52AEqW95YccO+e4S4gtsh2zMTObYYhV
3PKrn23A0MTCaqNgQeBz1NsKJ+wIOLNjwH4mSrFJI1bjUWxwVTpGKy+rwoilzS2/
sACgjWStwWQUfUu4Z9/D9uDs+Wsvkxf1EQlBj5wImbYo9+8nPPjFKJJIkEaDMd2F
aaSnZkYNX1IEu1BFUn6yM1kCj6QZo7p1oTJ8R7abBBKAAdqgEk7kwmcOsuKgTaoO
OIvNohkkmPY1SKognPi7JLAareA9++qeqJmuv/WKysEOlT6J7sdBlGp7gVxlw6QB
P17G3BO+6l1HEp7MHBUrNFI8WTmgouqP/FS4ZA2SUmJ2yQIHdI9rXCFoiuo743vy
FwiMIghjgkUatKxDnobW/it1qOEGmVJMyUV/rEcuAD2Xa6Mq/+XvF4zIzjnhmLAv
jMFi/xf9oN7cEAJHeiUHV+4FXHIT5HCqcenuHu7E8peoDGTw9HeQiG3eEHekr31w
G0f0xFSkB5Q544D9gnGsxF/5STLKnZ9Yo4p/NZXkQw1XJJXM8qewaln4Wm2FswiK
TzhlSTn/I4hGbOLE2cjuwn6epS+35nQClVD8npow8B+XTGNpWiKa3SOhMdDwdNFu
iOR0+5/H8V9/EhW7nehA24UMPV9M/Cf9qLHb5REX0HBkSgrQgo8=
=jQzU
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

Siri Cruise <chine.bleu@yahoo.com> writes:
>In article <nnd$0ce3b333$1344114e@5e8aa6fcc0002811>,
> Stef <me@this.is.invalid> wrote:
>
>> > How can that be true? All the experts are chiming in that it's
>> > impossible to have a stanardised and rigidly adhered to anything
>> > about the grid.
>>
>> Mains frequency is tightly controlled:
>
>No shit. But what about all the experts who chimed in that
>message passing on an AC grid was impossible because all the
>different operators made it too chaotic?

because there is _no_ message being passed. It's just a
constant frequency reference - a clock with no hands that
ticks 50 or 60 times a second.

In article <chine.bleu-1ABAF2.17492704032022@reader.eternal-september.org>,
Siri Cruise <chine.bleu@yahoo.com> wrote:
>In article <svuca0$f70$1@dont-email.me>,
> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>
>> And ERCOT in Texas tells people to not run their clocks based on the
>
>So Texas supplies residential and business customer DC instead of
>AC? Do they also replace on devices expecting AC?

Yes, Texas is totally screwed up (and Texans totally screwed) when it comes
to electricity distribution.

But they aren't (quite) *that* screwed up (as to mistakenly supply DC).

Yet...

--
You are again heaping damnation upon your own head by your statements.

- Rick C Hodgin -

On 04/03/2022 08:44, Kenny McCormack wrote:
> Yeah, but that's Texas.
>
> We now know (if we didn't already) with absolute certainty that Texas is
> weird and weirdly incompetent when it comes to electricity distribution and
> related topics.
>
> So, I'm not surprised they do it some weird way. Probably do it that way
> just to "own the libs".

I'm in the UK, and the smart meters use the mobile phone system.
(Cellphone in American)

Except where I live if I want to make a call I have to go outside, and
stand very still.

This is a really remote area of course. We're over 10 miles from the
centre of Cambridge.

They did suggest a smart meter. I explained. They checked and told me
"yes, we have had some installation failures in your area".

Apparently 92% of the UK has coverage from at least one operator. My
operator thinks I have good coverage inside the house and out.

Andy

On 04/03/2022 14:31, Dan Purgert wrote:
> And my microwave doesn't need an absolute reference either.
>
> Honestly though, even using the AC line sounds like its adding
> complexity for little (or no) benefit to my oven/microwave/etc. Also,
> how's it gonna handle different line frequency? As a manufacturer, am I
> gonna need half a dozen different designs of the same product to
> accommodate line frequency?

Let's see, one each for 110V and 230V; and one each for 50 and 60Hz.

Four.

Which they already do. Along with variations for the number of mains
plugs, of which there are a far higher number.

My microwave was built on the wrong side of Japan; the turntable spins 5
times a minute on our 50Hz, which means anything normal under a minute
isn't a whole number of turns and your handle is at the back.

I'm sure it would be OK on 60Hz, and 10 seconds would be a whole turn.

Andy

Vir Campestris <vir.campestris@invalid.invalid> writes:
>On 04/03/2022 14:31, Dan Purgert wrote:
>> And my microwave doesn't need an absolute reference either.
>>
>> Honestly though, even using the AC line sounds like its adding
>> complexity for little (or no) benefit to my oven/microwave/etc. Also,
>> how's it gonna handle different line frequency? As a manufacturer, am I
>> gonna need half a dozen different designs of the same product to
>> accommodate line frequency?
>
>Let's see, one each for 110V and 230V; and one each for 50 and 60Hz.
>
>Four.

One. With a jumper on the PCB that selects the target market,
set at manufacturing time. It's not rocket science.

On 2022-03-08, Scott Lurndal <scott@slp53.sl.home> wrote:
> Vir Campestris <vir.campestris@invalid.invalid> writes:
>>On 04/03/2022 14:31, Dan Purgert wrote:
>>> And my microwave doesn't need an absolute reference either.
>>>
>>> Honestly though, even using the AC line sounds like its adding
>>> complexity for little (or no) benefit to my oven/microwave/etc. Also,
>>> how's it gonna handle different line frequency? As a manufacturer, am I
>>> gonna need half a dozen different designs of the same product to
>>> accommodate line frequency?
>>
>>Let's see, one each for 110V and 230V; and one each for 50 and 60Hz.
>>
>>Four.
>
> One. With a jumper on the PCB that selects the target market,

Or when you move, taking your appliances from West Japan to East Japan
or vice versa. :)

Kaz Kylheku <480-992-1380@kylheku.com> writes:
>On 2022-03-08, Scott Lurndal <scott@slp53.sl.home> wrote:
>> Vir Campestris <vir.campestris@invalid.invalid> writes:
>>>On 04/03/2022 14:31, Dan Purgert wrote:
>>>> And my microwave doesn't need an absolute reference either.
>>>>
>>>> Honestly though, even using the AC line sounds like its adding
>>>> complexity for little (or no) benefit to my oven/microwave/etc. Also,
>>>> how's it gonna handle different line frequency? As a manufacturer, am I
>>>> gonna need half a dozen different designs of the same product to
>>>> accommodate line frequency?
>>>
>>>Let's see, one each for 110V and 230V; and one each for 50 and 60Hz.
>>>
>>>Four.
>>
>> One. With a jumper on the PCB that selects the target market,
>
>Or when you move, taking your appliances from West Japan to East Japan
>or vice versa. :)

Although most switching power supplies work seemlessly with 50-60hz
and 110-240vac.

On 10/03/2022 21:12, Scott Lurndal wrote:
> Kaz Kylheku <480-992-1380@kylheku.com> writes:
>> On 2022-03-08, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> Vir Campestris <vir.campestris@invalid.invalid> writes:
>>>> On 04/03/2022 14:31, Dan Purgert wrote:
>>>>> And my microwave doesn't need an absolute reference either.
>>>>>
>>>>> Honestly though, even using the AC line sounds like its adding
>>>>> complexity for little (or no) benefit to my oven/microwave/etc. Also,
>>>>> how's it gonna handle different line frequency? As a manufacturer, am I
>>>>> gonna need half a dozen different designs of the same product to
>>>>> accommodate line frequency?
>>>>
>>>> Let's see, one each for 110V and 230V; and one each for 50 and 60Hz.
>>>>
>>>> Four.
>>>
>>> One. With a jumper on the PCB that selects the target market,
>>
>> Or when you move, taking your appliances from West Japan to East Japan
>> or vice versa. :)
>
> Although most switching power supplies work seemlessly with 50-60hz
> and 110-240vac.

Most, but by no means all.

I have a 240v-110V transformer sitting on the floor next to me so I can
work from home with 110V only devices. The office has a 110V _and_ a
240V mains supply.

And yes, some do let out the magic smoke if you put a 110V device on a
240V supply.

50-60Hz hasn't been a problem for us, though I understand it can be for
motors.

Andy

I think Window's FILETIME and SYSTEM_TIME are the most elegant ways
to handle date-arithmetics. I've implemented this platform-independent
in C++:

// system_time.h:

#pragma once
#if defined(_MSC_VER)
#define NOMINMAX
#include <Windows.h>
#endif
#include <cstdint>
#include <compare>
#include <ctime>
#include <stdexcept>
#include <compare>

#if defined(_MSC_VER)
#pragma warning(push)
#pragma warning(disable: 26812) // prefer enum class over enum
#endif

struct system_time_t
{ std::uint16_t year;
std::uint8_t weekday, month, day;
std::uint8_t hour, minute, second;
std::uint32_t ns100;
};

struct system_time : public system_time_t
{ system_time() {}
system_time( system_time const & ) = default;
system_time( std::uint16_t year, std::uint8_t month, std::uint8_t day,
std::uint8_t hour, std::uint8_t minute, std::uint8_t second,
std::uint32_t ns100 );
system_time( std::uint64_t timestamp );
system_time( struct tm const &tm );
#if defined(_MSC_VER)
system_time( SYSTEMTIME const &st );
#endif
operator std::uint64_t() const;
system_time &operator =( std::uint64_t timestamp );
system_time &operator =( system_time const & ) = default;
operator tm() const;
system_time &operator =( struct tm const &tm );
#if defined(_MSC_VER)
operator SYSTEMTIME() const;
system_time &operator =( SYSTEMTIME const &st );
#endif
void adjust_weekday();
static std::uint8_t get_weekday( std::uint64_t timestamp );
static_assert(sizeof(time_t) == 8, "time_t must be 64 bit");
static time_t timestamp_to_time_t( uint64_t timestamp );
static uint64_t time_t_to_timestamp( time_t time );
struct date_error : public std::invalid_argument
{
enum reason_t : uint8_t
{
TIMESTAMP_BEYOND_63_BIT = 1,
YEAR_OUT_OF_RANGE,
MONTH_OUT_OF_RANGE,
DAY_OUT_OF_RANGE,
HOUR_OUT_OF_RANGE,
MINUTE_OUT_OF_RANGE,
SECOND_OUT_OF_RANGE,
NS100_OUT_OF_RANGE,
INVALID_WEEKDAY,
TIMESTAMP_BEFORE_TIME_T
};
reason_t reason();
private:
friend struct system_time;
date_error( reason_t reason );
reason_t m_reason;
};
private:
void assignFileTime( std::uint64_t timestamp );
static uint64_t const
MILLISECOND = 10'000,
SECOND = 1'000 * MILLISECOND,
MINUTE = 60 * SECOND,
HOUR = 60 * MINUTE,
DAY = 24 * HOUR,
WEEK = 7 * DAY,
NON_LEAP_YEAR = 365 * DAY,
LEAP_YEAR = 366 * DAY,
FOUR_YEARS_W_LJ = LEAP_YEAR + 3 * NON_LEAP_YEAR,
FOUR_YEARS_WO_LJ = 4 * NON_LEAP_YEAR,
FIRST_QUARTER_CENTURY = 25 * FOUR_YEARS_W_LJ,
REMAINING_QUARTER_CENUTRIES = 25 * FOUR_YEARS_W_LJ - DAY,
FOUR_HUNDRED_YEARS = FIRST_QUARTER_CENTURY + 3 *
REMAINING_QUARTER_CENUTRIES,
TIME_T_IN_TIMESTAMP_BEGIN = 0x19DB1DED53E800,
LAST_TIMESTAMP_IN_TIME_T = 0xD69433CCD5;
};

// may throw invalid_argument

inline
system_time::system_time( std::uint64_t timestamp )
{ assignFileTime( timestamp );
}

// may throw invalid_argument

inline
system_time &system_time::operator =( std::uint64_t timestamp )
{ assignFileTime( timestamp );
return *this;
}

inline
system_time::system_time( struct tm const &tm )
{ *this = tm;
}

#if defined(_MSC_VER)
inline
system_time::system_time( SYSTEMTIME const &st )
{ *this = st;
} #endif

inline
typename system_time::date_error::reason_t system_time::date_error::reason()
{ return m_reason;
}

// may throw date_error

inline
void system_time::adjust_weekday()
{ weekday = get_weekday( (uint64_t)*this );
}

inline
uint8_t system_time::get_weekday( uint64_t timestamp )
{ return (std::uint32_t)((timestamp - timestamp / WEEK * WEEK) / DAY + 1)
% 7;
}

// may throw date_error

inline
std::strong_ordering operator <=>( system_time_t const &left,
system_time_t const &right )
{ return (uint64_t)(system_time const &)left <=> (uint64_t)(system_time
const &)right;
}

// may throw date_error

inline
std::strong_ordering operator <=>( system_time_t const &left,
std::uint64_t right )
{ return (uint64_t)(system_time const &)left <=> right;
}

// may throw date_error

inline
std::strong_ordering operator <=>( std::uint64_t left, system_time_t
const &right )
{ return left <=> (uint64_t)(system_time const &)right;
}

#if defined(_MSC_VER)
#pragma warning(pop)
#endif

// system_time.cpp

#include <stdexcept>
#include <cassert>
#include <limits>
#include <algorithm>
#include <array>
#include <system_error>
#if defined(__cpp_lib_hardware_interference_size)
#include <new>
#endif
#include "system_time.h"

using namespace std;

#if defined(__cpp_lib_hardware_interference_size)
#define CL_SIZE std::hardware_destructive_interference_size
#else
#define CL_SIZE 64
#endif

//#define SYSTEM_TIME_BINARY_SEARCH

// may throw date_error

system_time::system_time( std::uint16_t year, std::uint8_t month,
std::uint8_t day, std::uint8_t hour, std::uint8_t minute, std::uint8_t
second, std::uint32_t ns100 )
{ this->year = year;
this->month = month;
this->day = day;
this->hour = hour;
this->minute = minute;
this->second = second;
this->ns100 = ns100;
this->weekday = get_weekday( (uint64_t)*this );
}

// may throw date_error

void system_time::assignFileTime( uint64_t timestamp )
{ if( timestamp > (uint64_t)numeric_limits<int64_t>::max() )
throw date_error( date_error::TIMESTAMP_BEYOND_63_BIT );
weekday = get_weekday( timestamp );
timestamp += LEAP_YEAR; // 1601 - 1600 = leap year
uint64_t tsCalc = timestamp;
uint16_t y400, y100, y4, y;
y400 = (uint16_t)(tsCalc / FOUR_HUNDRED_YEARS);
tsCalc -= y400 * FOUR_HUNDRED_YEARS;
bool isLeapYear;
auto leapQuad = [&]()
{
if( tsCalc >= LEAP_YEAR ) [[likely]]
// y >= 1
tsCalc -= LEAP_YEAR,
y = (uint16_t)(1 + tsCalc / NON_LEAP_YEAR), // 1 ... 3
tsCalc -= tsCalc / NON_LEAP_YEAR * NON_LEAP_YEAR,
isLeapYear = false;
else
// y == 0
y = 0,
isLeapYear = true;
};
if( tsCalc >= FIRST_QUARTER_CENTURY ) [[likely]]
{
// (y % 400) >= 100
y100 = (uint16_t)(1 + (tsCalc - FIRST_QUARTER_CENTURY) /
REMAINING_QUARTER_CENUTRIES); // 1 ... 3
tsCalc -= FIRST_QUARTER_CENTURY + (tsCalc - FIRST_QUARTER_CENTURY) /
REMAINING_QUARTER_CENUTRIES * REMAINING_QUARTER_CENUTRIES;
if( tsCalc >= FOUR_YEARS_WO_LJ ) [[likely]]
// (y % 400) >= 100 && (y % 4) >= 4
y4 = (uint16_t)(1 + (tsCalc - FOUR_YEARS_WO_LJ) / FOUR_YEARS_W_LJ),
// 1 ... 24
tsCalc -= FOUR_YEARS_WO_LJ + (tsCalc - FOUR_YEARS_WO_LJ) /
FOUR_YEARS_W_LJ * FOUR_YEARS_W_LJ,
leapQuad();
else
// (y % 400) >= 100 && (y % 4) < 4
y4 = 0,
y = (uint16_t)(tsCalc / NON_LEAP_YEAR),
tsCalc -= tsCalc / NON_LEAP_YEAR * NON_LEAP_YEAR,
isLeapYear = false;
}
else
// (y % 400) < 100
y100 = 0,
y4 = (uint16_t)(tsCalc / FOUR_YEARS_W_LJ),
tsCalc -= tsCalc / FOUR_YEARS_W_LJ * FOUR_YEARS_W_LJ,
leapQuad();
year = 1600 + 400 * y400 + 100 * y100 + 4 * y4 + y;
{
static
uint64_t const alignas(CL_SIZE) monthOffsets[2][12 + 1] =
{
{ 0 * DAY, 31 * DAY, 59 * DAY, 90 * DAY, 120 * DAY, 151 * DAY, 181 *
DAY, 212 * DAY, 243 * DAY, 273 * DAY, 304 * DAY, 334 * DAY, 999 * DAY },
{ 0 * DAY, 31 * DAY, 60 * DAY, 91 * DAY, 121 * DAY, 152 * DAY, 182 *
DAY, 213 * DAY, 244 * DAY, 274 * DAY, 305 * DAY, 335 * DAY, 999 * DAY }
};
uint64_t const *pMonthOffsets = monthOffsets[isLeapYear];
#if defined(SYSTEM_TIME_BINARY_SEARCH)
size_t lower = 0, upper = 12, hit = -1, mid;
do
{
mid = (lower + upper) / 2;
if( pMonthOffsets[mid] <= tsCalc )
hit = mid,
lower = mid + 1;
else
upper = mid;
} while( lower != upper );
#else
size_t hit;
for( hit = 0; tsCalc >= pMonthOffsets[hit + 1]; ++hit );
#endif
assert(hit != -1);
uint8_t dy = (uint8_t)((tsCalc - pMonthOffsets[hit]) / DAY);
tsCalc -= pMonthOffsets[hit] + dy * DAY;
month = 1 + (uint8_t)hit;
day = 1 + dy;
}
hour = (uint8_t)(tsCalc / HOUR);
tsCalc %= HOUR;
minute = (uint8_t)(tsCalc / MINUTE);
tsCalc %= MINUTE;
second = (uint8_t)(tsCalc / SECOND);
tsCalc %= SECOND;
ns100 = (uint32_t)tsCalc;
}

// may throw date_error

system_time::operator std::uint64_t() const
{ if( year < 1601 || year > 30828 ) [[unlikely]]
throw date_error( date_error::YEAR_OUT_OF_RANGE );
if( month < 1 || month > 12 ) [[unlikely]]
throw date_error( date_error::MONTH_OUT_OF_RANGE );
bool isLeapYear = year % 4 == 0 && year % 100 != 0 || year % 400 == 0;
static
uint8_t const alignas(CL_SIZE) monthLengths[2][1 + 12] =
{
{ 0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
{ 0, 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
};
if( day == 0 || day > monthLengths[isLeapYear][month] ) [[unlikely]]
throw date_error( date_error::DAY_OUT_OF_RANGE );
if( hour >= 24 ) [[unlikely]]
throw date_error( date_error::HOUR_OUT_OF_RANGE );
if( minute >= 60 ) [[unlikely]]
throw date_error( date_error::MINUTE_OUT_OF_RANGE );
if( second >= 60 ) [[unlikely]]
throw date_error( date_error::SECOND_OUT_OF_RANGE );
if( ns100 >= 10'000'000 ) [[unlikely]]
throw date_error( date_error::NS100_OUT_OF_RANGE );
uint16_t yr = year - 1600;
uint64_t timestamp = yr / 400 * FOUR_HUNDRED_YEARS;
yr %= 400;
auto leapQuad = [&]()
{
timestamp += yr / 4 * FOUR_YEARS_W_LJ;
yr %= 4;
if( yr >= 1 ) [[likely]]
timestamp += LEAP_YEAR + (yr - 1) * NON_LEAP_YEAR;
};
if( yr >= 100 ) [[likely]]
{
timestamp += FIRST_QUARTER_CENTURY;
yr -= 100;
timestamp += yr / 100 * REMAINING_QUARTER_CENUTRIES;
yr %= 100;
if( yr >= 4 ) [[likely]]
timestamp += FOUR_YEARS_WO_LJ,
yr -= 4,
leapQuad();
else
timestamp += yr * NON_LEAP_YEAR;
}
else
leapQuad();
timestamp -= LEAP_YEAR; // - (1.1.1601 - 1.1.1600)
static
uint16_t const alignas(CL_SIZE) monthOffsets[2][1 + 12] =
{
{ 0, 0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334 },
{ 0, 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335 }
};
timestamp += (monthOffsets[isLeapYear][month] + day - 1) * DAY;
timestamp += hour * HOUR;
timestamp += minute * MINUTE;
timestamp += second * SECOND;
timestamp += ns100;
if( timestamp > (uint64_t)numeric_limits<int64_t>::max() )
throw date_error( date_error::NS100_OUT_OF_RANGE );
return timestamp;
}