On 16/05/2018 11:11, Mark Rotteveel wrote:
>
> If you look at PostgreSQL, they release a new point release with
> updated time zone data. I don't see why we need to make this more
> complicated than that.
>
> However that does mean, that we need to have a quick turn-around time
> for new releases (
On 14-5-2018 09:13, Simonov Denis via Firebird-devel wrote:
Adriano dos Santos Fernandes wrote Thu, 10 May
2018 18:21:49 +0300:
Hi!
I want to create a virtual table that lists available time zones.
For now there is RDB$ (non-virtual), MON$ (virtual, but all about
monitoring), SEC$ (security
On 15/05/18 10:18, Alex Peshkoff via Firebird-devel wrote:
Look how MSK time zone was changed at 2014.10.26
https://www.timeanddate.com/time/zone/russia/moscow
I think about something like this:
ID Name Valid from Offset
... MSK 2011.03.27 02:00 +4
... MSK 2014.10
On 05/10/18 19:40, Vlad Khorsun via Firebird-devel wrote:
10.05.2018 19:23, Adriano dos Santos Fernandes wrote:
On 10/05/2018 13:12, Vlad Khorsun via Firebird-devel wrote:
I guess the question is about the case when users have historical
data
and need to apply old time zone rule to the ol
10.05.2018 19:23, Adriano dos Santos Fernandes wrote:
On 10/05/2018 13:12, Vlad Khorsun via Firebird-devel wrote:
I guess the question is about the case when users have historical data
and need to apply old time zone rule to the old data and new timezone
rule
to the new data.
Is it possi
On 14/05/2018 10:24, Dimitry Sibiryakov wrote:
>
> It doesn't need to be DDL. Stored procedures in timezone package
> should be enough.
>
> What are packages for if even developers don't want to use them?..
>
>
If by developers you mean core team, for example:
- Do not improve the hell of not
14.05.2018 14:55, Vlad Khorsun via Firebird-devel wrote:
Can I register a new rule for time zones without updating Firebird and the
backup/restore process?
If so, is there a DLL syntax for registering a new time zone rule?
This is interesting and valid question (as for me). With such possib
On 14/05/18 14:02, Adriano dos Santos Fernandes wrote:
So he updates original db and ICU and have what he wants.
That only works if TZ is installed using the backzone data, and as you
have seen this is not the case. The real world solution for this IS
TZDist ... and you would simply patch any l
On 14/05/18 13:55, Vlad Khorsun via Firebird-devel wrote:
Can I register a new rule for time zones without updating Firebird and
the backup/restore process?
If so, is there a DLL syntax for registering a new time zone rule?
This is interesting and valid question (as for me). With such
poss
On 14/05/2018 09:30, Lester Caine wrote:
> On 14/05/18 13:22, Adriano dos Santos Fernandes wrote:
>>> Can I register a new rule for time zones without updating Firebird and
>>> the backup/restore process?
>>> If so, is there a DLL syntax for registering a new time zone rule?
>>>
>> Serious, you wan
On 14/05/2018 09:55, Vlad Khorsun via Firebird-devel wrote:
>
>> Can I register a new rule for time zones without updating Firebird
>> and the backup/restore process?
>> If so, is there a DLL syntax for registering a new time zone rule?
>
> This is interesting and valid question (as for me). With
14.05.2018 10:13, Simonov Denis via Firebird-devel wrote:
I'm wondering how the time zones will be updated?
See "Updating the Time Zone Data" at
http://userguide.icu-project.org/datetime/timezone
Will they be distributed as a separate file in Firebird?
So far i see no need for
On 14/05/18 13:22, Adriano dos Santos Fernandes wrote:
Can I register a new rule for time zones without updating Firebird and
the backup/restore process?
If so, is there a DLL syntax for registering a new time zone rule?
Serious, you want resgister custom time zones rules?
I read that simply
On 14/05/2018 04:13, Simonov Denis via Firebird-devel wrote:
> Adriano dos Santos Fernandes wrote Thu, 10 May
> 2018 18:21:49 +0300:
>
>> Hi!
>>
>> I want to create a virtual table that lists available time zones.
>>
>> For now there is RDB$ (non-virtual), MON$ (virtual, but all about
>> monitorin
Adriano dos Santos Fernandes wrote Thu, 10 May 2018
18:21:49 +0300:
Hi!
I want to create a virtual table that lists available time zones.
For now there is RDB$ (non-virtual), MON$ (virtual, but all about
monitoring), SEC$ (security plugin).
What prefix should TIME_ZONES have?
Adriano
I
11.05.2018 13:22, Adriano dos Santos Fernandes wrote:
I do not thought about it, but would be very good to put them in another
virtual table if possible.
May be a package with a set of procedures would be better then?..
--
WBR, SD.
On 11/05/2018 01:20, Vlad Khorsun via Firebird-devel wrote:
>
>>
>> Every range (x-y) must define a displacement.
>
> Good, now it is much more clear (for me, at least).
> It there a way to query\extract this ranges and coresponding
> displacements ?
>
I do not thought about it, but would be very
11.05.2018 1:27, Adriano dos Santos Fernandes wrote:
On 10/05/2018 18:03, Vlad Khorsun via Firebird-devel wrote:
...
Could you answer my question below ?
Please, convert to UTC and explain how to do it:
2010.03.01 04:00 Europe/Moscow,
2013.03.01 04:00 Europe/Moscow,
2016.03.01
On 10/05/2018 19:27, Adriano dos Santos Fernandes wrote:
> Here I show interesting example when DST starts.
Correction: when DST *ends*.
Adriano
--
Check out the vibrant tech community on one of the world's most
engagi
On 10/05/2018 18:03, Vlad Khorsun via Firebird-devel wrote:
>
> To do it, you need to know TZ (or, offset from UTC) used at
> America/Sao_Paulo
> at given moment, isn't is ? And this offset is also depends on given moment
> itself. And in different moments there could be different offsets.
> Co
On 10/05/18 22:30, Leyne, Sean wrote:
No other database engine is maintaining various versions at the same
time.
Fortunately.
I believe that Oracle is.
I already put here link describing that when tz db is updated, times may
change if used in wrong version.
I think I misunderstood which "ve
On 10/05/18 19:57, Adriano dos Santos Fernandes wrote:
I can give more examples of problems which NOT knowing which rule set
was used to create the 'international' timetable when local DST times
are changed at short notice ... TZDist is intended to prevent this
problem, but since there are no act
> Store your data using the displacement syntax +/- HH:MM and add the
> region name to another column.
What would be required to have the "displacement syntax" implicitly used for
all ISQL operations?
For example
UPDATE Table SET
UpdateDatetime = 'NOW'
;
Sean
--
> >> No other database engine is maintaining various versions at the same
> time.
> >> Fortunately.
> >
> > I believe that Oracle is.
> >
>
> How?
>
> I already put here link describing that when tz db is updated, times may
> change if used in wrong version.
I think I misunderstood which "vers
On 10/05/2018 18:22, Leyne, Sean wrote:
>
>
>> No other database engine is maintaining various versions at the same time.
>> Fortunately.
>
> I believe that Oracle is.
>
How?
I already put here link describing that when tz db is updated, times may
change if used in wrong version.
Adriano
> No other database engine is maintaining various versions at the same time.
> Fortunately.
I believe that Oracle is.
Sean
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashd
10.05.2018 22:08, Adriano dos Santos Fernandes wrote:
On 10/05/2018 15:30, Vlad Khorsun via Firebird-devel wrote:
The key is that DST doesn't affect given time zone. TZ could be
"standard time" based (such as MSK)
or "DST based" (such as MSD or IST you speak about) but TZ itself is
not chang
On 10/05/2018 15:30, Vlad Khorsun via Firebird-devel wrote:
>
> The key is that DST doesn't affect given time zone. TZ could be
> "standard time" based (such as MSK)
> or "DST based" (such as MSD or IST you speak about) but TZ itself is
> not changed with DST start\end.
> What is changed - is wha
On 10/05/2018 15:31, Lester Caine wrote:
> On 10/05/18 18:47, Adriano dos Santos Fernandes wrote:
>> 99.9% of our users will use the "official" database.
>
> And therefore will have no idea just which "official" database they
> are using. This is just carrying on the current mess that is inherent
>
On 10/05/18 19:30, Vlad Khorsun via Firebird-devel wrote:
The key is that DST doesn't affect given time zone. TZ could be
"standard time" based (such as MSK)
or "DST based" (such as MSD or IST you speak about) but TZ itself is not
changed with DST start\end.
What is changed - is what TZ shou
10.05.2018 21:21, Adriano dos Santos Fernandes wrote:
The name for Moskow is Europe/Moscow.
Please, convert to UTC and explain how to do it:
2010.03.01 04:00 Europe/Moscow,
2013.03.01 04:00 Europe/Moscow,
2016.03.01 04:00 Europe/Moscow
Regards,
Vlad
--
On 10/05/18 18:47, Adriano dos Santos Fernandes wrote:
99.9% of our users will use the "official" database.
And therefore will have no idea just which "official" database they are
using. This is just carrying on the current mess that is inherent when
one has no idea just which rules WERE USED
10.05.2018 21:13, Lester Caine wrote:
On 10/05/18 18:47, Vlad Khorsun via Firebird-devel wrote:
Regions that use Daylight Saving Time (DST) change the time zone name and time during the DST period. The words “daylight” or
“summer” are then usually included in the time zone name. The areas that d
On 10/05/2018 14:47, Vlad Khorsun via Firebird-devel wrote:
>
> According to:
>
> https://www.timeanddate.com/time/time-zones.html
>
> ---
> Daylight Saving Time Zones
>
> Regions that use Daylight Saving Time (DST) change the time zone name
> and time during the DST period. The words “daylig
On 10/05/18 18:47, Vlad Khorsun via Firebird-devel wrote:
Regions that use Daylight Saving Time (DST) change the time zone name
and time during the DST period. The words “daylight” or “summer” are
then usually included in the time zone name. The areas that don't use
DST remain on standard time
On 10/05/2018 14:47, Dimitry Sibiryakov wrote:
> 10.05.2018 19:14, Adriano dos Santos Fernandes wrote:
>>> IMHO, one of advantages of using UDR for subj is that much more
>>> fields can be added any time as needed by upgrading a single library
>>> while a virtual table is fixed to ODS and has to
10.05.2018 19:14, Adriano dos Santos Fernandes wrote:
IMHO, one of advantages of using UDR for subj is that much more
fields can be added any time as needed by upgrading a single library
while a virtual table is fixed to ODS and has to be decided once and
forever.
UDR needs metadata too, so
On 10/05/2018 13:32, Lester Caine wrote:
> This is exactly the problem, and using TZ data direct is the only
> reliable way to manage the CURRENT TZ rules. So as long as we can
> switch off ICU data then this may work, otherwise it is just another
> waste of time! In my case all the TZ material is
10.05.2018 20:29, Adriano dos Santos Fernandes пишет:
On 10/05/2018 14:23, Vlad Khorsun via Firebird-devel wrote:
Look how MSK time zone was changed at 2014.10.26
https://www.timeanddate.com/time/zone/russia/moscow
I think about something like this:
ID Name Valid from Offse
On 10/05/18 17:24, Adriano dos Santos Fernandes wrote:
Would that name be the full name like Europe/Amsterdam, or would it
also include the imprecise (duplicates are possible) like CET?
Both, each one has a different ID.
There are multiple abbreviations that relate to different rules. Only
t
On 10/05/2018 14:29, Adriano dos Santos Fernandes wrote:
> In practical terms, it's the same as a DST change.
>
> A DST is nothing different than a "rule change" and another "rule
> change" every year.
>
>
Some time zones nomenclature are specific to the region's standard or
DST times, so they are
On 10/05/2018 14:23, Vlad Khorsun via Firebird-devel wrote:
>
>>> Look how MSK time zone was changed at 2014.10.26
>>>
>>> https://www.timeanddate.com/time/zone/russia/moscow
>>>
>>> I think about something like this:
>>>
>>> ID Name Valid from Offset
>>> ... MSK 2011.03.27 02
10.05.2018 19:57, Adriano dos Santos Fernandes пишет:
On 10/05/2018 13:47, Vlad Khorsun via Firebird-devel wrote:
10.05.2018 19:23, Adriano dos Santos Fernandes wrote:
On 10/05/2018 13:12, Vlad Khorsun via Firebird-devel wrote:
I guess the question is about the case when users have histor
On 10/05/2018 14:08, Dimitry Sibiryakov wrote:
> 10.05.2018 18:44, Vlad Khorsun via Firebird-devel wrote:
>> Is it possible\make sence to add a datetime field with "valid from"
>> mark ? Or something like that, some kind of version mark.
>
> IMHO, one of advantages of using UDR for subj is tha
10.05.2018 18:44, Vlad Khorsun via Firebird-devel wrote:
Is it possible\make sence to add a datetime field with "valid from"
mark ? Or something like that, some kind of version mark.
IMHO, one of advantages of using UDR for subj is that much more fields can be added any
time as needed by
On 10/05/2018 13:47, Vlad Khorsun via Firebird-devel wrote:
> 10.05.2018 19:23, Adriano dos Santos Fernandes wrote:
>> On 10/05/2018 13:12, Vlad Khorsun via Firebird-devel wrote:
>>>
>>> I guess the question is about the case when users have historical
>>> data
>>> and need to apply old time zon
10.05.2018 19:23, Adriano dos Santos Fernandes wrote:
On 10/05/2018 13:12, Vlad Khorsun via Firebird-devel wrote:
I guess the question is about the case when users have historical data
and need to apply old time zone rule to the old data and new timezone
rule
to the new data.
Is it possi
10.05.2018 19:02, Adriano dos Santos Fernandes wrote:
On 10/05/2018 12:53, Lester Caine wrote:
...
And how will the version of TZ data be handled! This is a key element
that has screwed normalized data in the past, and some way to manage
that normalized data needs to be included in the process.
> 10.05.2018 19:02, Adriano dos Santos Fernandes wrote:
> > On 10/05/2018 12:53, Lester Caine wrote:
> ...
> >> And how will the version of TZ data be handled! This is a key element
> >> that has screwed normalized data in the past, and some way to manage
> >> that normalized data needs to be inc
On 10/05/18 17:12, Vlad Khorsun via Firebird-devel wrote:
10.05.2018 19:02, Adriano dos Santos Fernandes wrote:
On 10/05/2018 12:53, Lester Caine wrote:
...
And how will the version of TZ data be handled! This is a key element
that has screwed normalized data in the past, and some way to manag
On 10/05/2018 13:22, Mark Rotteveel wrote:
>
>> NAME VARCHAR
>
> Would that name be the full name like Europe/Amsterdam, or would it
> also include the imprecise (duplicates are possible) like CET?
>
Both, each one has a different ID.
Adriano
---
On 10/05/2018 13:12, Vlad Khorsun via Firebird-devel wrote:
>
> I guess the question is about the case when users have historical data
> and need to apply old time zone rule to the old data and new timezone
> rule
> to the new data.
>
> Is it possible\make sence to add a datetime field with "va
On 10-5-2018 17:51, Adriano dos Santos Fernandes wrote:
On 10/05/2018 12:27, Alex Peshkoff via Firebird-devel wrote:
On 05/10/18 18:21, Adriano dos Santos Fernandes wrote:
Hi!
I want to create a virtual table that lists available time zones.
For now there is RDB$ (non-virtual), MON$ (virtual,
10.05.2018 19:02, Adriano dos Santos Fernandes wrote:
On 10/05/2018 12:53, Lester Caine wrote:
...
And how will the version of TZ data be handled! This is a key element
that has screwed normalized data in the past, and some way to manage
that normalized data needs to be included in the process.
On 10/05/2018 13:00, Dimitry Sibiryakov wrote:
> 10.05.2018 17:57, Adriano dos Santos Fernandes wrote:
>> May make sense, but I think we didn't defined what is the difference
>> between a virtual table and these things, specially that a view would
>> also accept update/delete that triggers an actio
On 10/05/2018 12:53, Lester Caine wrote:
> On 10/05/18 16:27, Leyne, Sean wrote:
>> Q's: How will the data be defined? In code or via some external
>> file? If external, how will changes be applied/recognized to running
>> engine instance?
>
> And how will the version of TZ data be handled! This
10.05.2018 17:57, Adriano dos Santos Fernandes wrote:
May make sense, but I think we didn't defined what is the difference
between a virtual table and these things, specially that a view would
also accept update/delete that triggers an action, a thing currently
used in virtual tables.
The UDR
On 10/05/2018 12:39, Dimitry Sibiryakov wrote:
> 10.05.2018 17:21, Adriano dos Santos Fernandes wrote:
>> I want to create a virtual table that lists available time zones.
>
> Why a virtual table instead of UDR or a view based on UDR? Using of
> UDR would provide more flexibility and guarantee th
On 10/05/2018 12:27, Leyne, Sean wrote:
>
> Q's: How will the data be defined? In code or via some external file? If
> external, how will changes be applied/recognized to running engine instance?
>
>
Currently the data (only mapping from Firebird ID to ICU time zone name)
is defined at the code
On 10/05/18 16:27, Leyne, Sean wrote:
Q's: How will the data be defined? In code or via some external file? If
external, how will changes be applied/recognized to running engine instance?
And how will the version of TZ data be handled! This is a key element
that has screwed normalized data
On 10/05/2018 12:27, Alex Peshkoff via Firebird-devel wrote:
> On 05/10/18 18:21, Adriano dos Santos Fernandes wrote:
>> Hi!
>>
>> I want to create a virtual table that lists available time zones.
>>
>> For now there is RDB$ (non-virtual), MON$ (virtual, but all about
>> monitoring), SEC$ (security
10.05.2018 18:28, Mark Rotteveel wrote:
I don't see any reason why a virtual table can't have a RDB$ prefix.
+1
Dmitry
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot
10.05.2018 17:21, Adriano dos Santos Fernandes wrote:
I want to create a virtual table that lists available time zones.
Why a virtual table instead of UDR or a view based on UDR? Using of UDR would provide
more flexibility and guarantee that data are actual.
--
WBR, SD.
---
On 10-5-2018 17:21, Adriano dos Santos Fernandes wrote:
Hi!
I want to create a virtual table that lists available time zones.
For now there is RDB$ (non-virtual), MON$ (virtual, but all about
monitoring), SEC$ (security plugin).
What prefix should TIME_ZONES have?
Where is schema support whe
On 05/10/18 18:21, Adriano dos Santos Fernandes wrote:
Hi!
I want to create a virtual table that lists available time zones.
For now there is RDB$ (non-virtual), MON$ (virtual, but all about
monitoring), SEC$ (security plugin).
What prefix should TIME_ZONES have?
Can you provide a small samp
Adriano,
> I want to create a virtual table that lists available time zones.
>
> For now there is RDB$ (non-virtual), MON$ (virtual, but all about monitoring),
> SEC$ (security plugin).
>
> What prefix should TIME_ZONES have?
My feeling is to use the RDB$ prefix.
Q's: How will the data be def
66 matches
Mail list logo
